Google app engine 游标处理最终一致性吗？

在App Engine文档中，我发现了通过使用游标来更新数据存储中的更改的方法：

游标的一个有趣应用是监视实体中看不见的更改。如果应用程序在每次实体更改时使用当前日期和时间设置时间戳属性，则应用程序可以使用按时间戳属性排序的查询（升序），并使用数据存储光标检查实体何时移动到结果列表的末尾。如果更新了实体的时间戳，则带有光标的查询将返回更新后的实体。如果自上次执行查询以来未更新任何实体，则不会返回任何结果，并且光标不会移动

然而，我不太确定这是如何始终起作用的。毕竟，在使用高复制数据存储时，查询最终是一致的。因此，如果放置了两个实体，并且查询只看到这两个实体中较晚的一个，那么它会将光标移过这两个实体。这将意味着这两个新实体中的第一个仍将不可见

---

那么这是一个实际问题吗？或者有其他方法可以让游标解决这个问题吗？

如果您可以询问从事此工作的人员，您可能会得到最好的信息，但是在仔细考虑并重新阅读Paxos之后，我认为这应该不是一个问题，尽管这取决于数据存储的实际实现方式

光标本质上是索引中的一个位置。理论上，您可以反复读取同一个光标，并看到新的实体开始出现在它之后。在现实世界中，您通常会移动到最新的光标位置，而忘记旧的光标位置

最终出现一致性“问题”，因为索引的多个副本分布在多台机器上。根据读取的索引，可能会得到过时的结果

您描述了一个问题案例，其中索引I有两个（精确的）副本，并且创建了两个新实体E1和E2。假设I1=I+E1和I2=I+E2，因此根据您从中读取的索引，您可能会将E1或E2作为新实体，移动光标，并在索引与其他索引“修补”时丢失实体，即I2最终修补为I+E1+E2

如果数据存储确实是这样，那么我怀疑，是的，您可能会遇到问题。然而，这样操作听起来非常困难，我怀疑数据存储索引只有在Paxos投票达成一致后才会更新。所以，你永远不会看到无序索引，你只会看到实体出现得很晚：也就是说，你永远不会看到I+E2，你只会看到（I）或（I+E1）或（I+E1+E2）

---

不过，我怀疑您可能会遇到这样的问题：对于尚未跟上的索引来说，光标太新了。

在包含单调递增值（如当前时间戳）的属性上使用内置或复合索引，可能无法在高写入率下达到您所希望的效果。这种类型的工作负载将生成一个热点，因为索引的尾部会不断更新，而不是将负载分布在整个已排序的索引中。但是，对于低写入速率，这将很好地工作

答案的其余部分将取决于您是在同一实体组中还是在单独的实体组中

如果您的查询是一个祖先查询，因此在同一个实体组中，它可以是强一致的（默认情况下是一致的），并且所描述的方法应该总是准确的。查询将立即看到任何写入（对实体组内实体的更改）

如果查询多个实体组（最终总是一致的），则无法保证应用/可见写入的顺序。例如： -时间1-写入实体a -时间2-写入实体B -Time3-查询只看到EntityB -Time4-查询看到EntityA和EntityB

因此，使用光标检测更改的方法是正确的，但它可能会“跳过”某些更改

---

有关最终/强一致性的更多信息，请参阅

谢谢！根据你个人资料的网站，我假设你在谷歌工作。。。Dragonx在他的回答中假设：“[…]你永远不会看到无序的索引，你只会看到实体出现得很晚”——这意味着它不会跳过任何更改。你能评论一下他的理论是否正确吗？