python - 实际上，HRD 中的 "eventual consistency"最终是多少？

Question

我正在将应用程序从主/从迁移到 HRD。我想听听已经完成迁移的人的一些评论。

1. 我尝试了一个简单的示例，仅发布一个没有祖先的新实体并重定向到一个页面以列出该模型中的所有实体。我试了几次，它总是一致的。我为它们添加了 500 个索引属性，并且始终保持一致...

2. 我还担心某些声称每个实体组每秒只能执行 1 次 put() 的限制。我 put() 30 个具有相同祖先的实体(相同的 HTTP 请求，但一个接一个地 put())，这与放置 30 个没有祖先的实体基本上没有区别。 (我正在使用 NDB，它会不会做某种优化？)

我用一个没有任何流量的空应用程序对此进行了测试，我想知道实际流量会在多大程度上影响“最终一致性”。

我知道我可以测试本地开发的“最终一致性”。我的问题是:

我真的需要重组我的应用程序来处理最终一致性吗？

或者因为最终一致性实际上在 99% 的实践中是一致的，就让它保持原样是可以接受的？

Answer 1

如果您有一个小型应用程序，那么您的数据可能位于同一磁盘的同一部分，并且您只有一个实例。您可能不会注意到最终一致性。随着您的应用程序的增长，您会更多地注意到它。通常需要几毫秒才能达到一致性，但我见过需要一个小时或更长时间的情况。

通常，查询是您最常注意到的地方。减少影响的一种方法是仅按键查询，然后使用 ndb.get_multi() 加载实体。通过键获取实体可确保您获得该实体的最新版本。但是，它不能保证键列表是高度一致的。所以你可能会得到与查询条件不匹配的实体，所以循环遍历实体并跳过不匹配的实体。

根据我的观察，最终一致性带来的痛苦会随着应用的增长而逐渐增长。在某些时候，您确实需要认真对待它并更新代码的关键区域来处理它。