ndb强一致性和频繁写入

Question

我正在尝试使用python与ndb实现强一致性。看起来我错过了一些东西，因为我的读取表现得好像它们不太一致。

查询是：

links = Link.query(ancestor=lead_key).filter(Link.last_status == 
None).fetch(keys_only=True)

if links: 
    do_action() 

关键结构是：

Lead root (generic key) -> Lead -> Website (one per lead) -> Link

我有许多使用TaskQueue同时执行的任务，并且此查询在每个任务结束时执行。有时我在更新last_status字段时会遇到“过多争用”异常，但我会使用重试来处理它。它会破坏强一致性吗？

预期的行为是，当没有剩余的链接的最后一个\u状态等于无时，调用了do\u action（）。实际行为是不一致的：有时调用两次，有时根本不调用。

Answer 1

示例中没有任何内容可以确保代码只被调用一次。

目前，我假设您的“do\u action”函数对链接实体做了一些事情，特别是它设置了“last\u status”属性。

如果不在事务中执行查询和对链接实体的写入，则两个不同的请求（任务队列任务）可能会从查询中获取结果，然后将其新值写入链接实体（最后一次写入会覆盖以前的值）。

请记住，即使您确实使用了事务，在事务成功完成之前，您也不知道没有其他人尝试执行写入。如果您尝试执行数据存储之外的操作（例如，向外部系统发出超文本传输协议请求），这一点很重要，因为您可能会看到来自事务的超文本传输协议请求最终会因并发修改异常而失败。

Answer 2

添加到戴夫的答案是第一件要检查的事情。

有一件事没有很好的文档记录，可能有点令人惊讶，那就是争用也可能是由读操作引起的，而不仅仅是由写操作引起的。

每当事务启动时，被访问的实体组（通过读取或写入操作，没关系）都会被标记为这样。太多争用错误表明太多并行事务同时尝试访问同一个实体组。即使没有任何事务实际尝试写入，也可能发生！

注意：开发服务器不会模拟此争用，只有在GAE上部署真实的数据存储时才能看到它！

更令人困惑的是事务的自动重试，这可能发生在实际的写入冲突或简单的访问争用之后。这些重试在最终用户看来可能是某些代码路径的可疑重复执行——我怀疑这可以解释您关于调用两次do_action（）的报告。

通常，当您遇到此类问题时，您必须重新访问您的数据结构和/或访问它们的方式（您的事务）。除了保持强一致性的解决方案（这可能非常昂贵）之外，您可能还需要重新检查一致性是否真的是必须的。在某些情况下，它被添加为一揽子要求只是因为看起来简化了事情。根据我的经验，它没有：）

Answer 3

使用祖先键来获得强一致性有一个限制：每个实体组每秒只能更新一次。解决这个问题的一种方法是对实体组进行分片。分片计数器描述了这种技术。这是一篇旧文章，但据我所知，建议仍然合理。