我正在将应用程序从Master / Slave迁移到HRD。我想听听已经完成迁移的人的一些意见。
我尝试了一个简单的例子来发布一个没有祖先的新实体，并重定向到一个页面以列出该模型中的所有实体。我试了好几次，总是一致的。他我把500个索引属性再次保持一致......
我还担心每个实体组每秒限制一个1 put（）。我把（）30个实体与相同的祖先（相同的HTTP请求，但逐个put）放在一起，这与没有祖先的30个实体基本没有区别。 （我正在使用NDB，它可以进行某种优化吗？）
我使用空的应用程序对此进行了测试，没有任何流量，我想知道实际流量会对“最终一致性”产生多大影响。
我知道我可以测试本地开发的“最终一致性”。我的问题是：
我是否真的需要重构我的应用以处理最终的一致性？
或者保留它的方式是可以接受的，因为最终的一致性在实践中实际上是99％一致的吗？
答案 0 :(得分：1)
如果您有一个小应用程序，那么您的数据可能存在于同一磁盘的同一部分，并且您有一个实例。您可能不会注意到最终的一致性。随着您的应用程序的增长，您会注意到它。通常需要几毫秒才能达到一致性，但我已经看到需要一个小时或更长时间的情况。
通常，查询是您最常注意到的地方。减少影响的一种方法是仅按键查询，然后使用ndb.get_multi（）加载实体。按键获取实体可确保您获得该实体的最新版本。但是，它并不保证密钥列表具有很强的一致性。因此，您可能会获得与查询条件不匹配的实体，因此循环实体并跳过不匹配的实体。
从我注意到，随着应用程序的增长，最终一致性的痛苦逐渐增加。在某些时候，您需要认真对待并更新代码的关键区域来处理它。
答案 1 :(得分：0)
如果结果不一致，最糟糕的情况是什么？
用户是否看到一些过时的不重要信息？那可能没问题。
你会错误估算一些重要的东西，比如价格吗？或者商店中库存的商品数量？在这种情况下，您可能希望避免这种偶然发生。
仅从观察结果看，最终一致的结果会随着您的数据集变大而显得更多，我怀疑您的数据会分散在更多平板电脑上。
此外，如果您使用key / id通过get（）请求读回实体，它将始终保持一致。确保您正在进行查询以获得最终一致的结果。
答案 2 :(得分：0)
复制速度主要取决于服务器工作负载。通常在卸载的系统上，复制延迟将是毫秒。
但“最终一致”的想法是你需要编写你的应用程序，这样你才不会依赖它;任何复制延迟都需要在您的应用程序的约束范围内允许。