google-app-engine - 如何处理 fork-join-queue 中的最终一致性

Question

我目前正在寻找替换以下视频中描述的有缺陷的 fork-join-queue 实现:

https://youtu.be/zSDC_TU7rtc?t=33m37s

我意识到这个视频已经有将近八年的历史了，我很乐意学习任何潜在的新的和更好的方法来做这些事情，但现在我正专注于尝试按照描述的方式完成这项工作布雷特。目前，摆在我面前的有点乱。

原始开发人员与 Brett 不同的地方之一是，他将特定 sum_name 的所有工作项放入单个实体组中。

我对数据存储还比较陌生，但对我来说这似乎违背了整个目的，因为每秒多次向实体组添加新实体会引起争用，而这正是我们正在尝试的事情通过批处理更改来避免。

至于为什么有人会尝试将所有工作放在一个实体组中，原始开发人员的评论很明确——他试图防止工作项因最终一致性而被跳过。这让我真正深入研究了 Brett 的实现，我感到非常困惑，因为这似乎是 Brett 没有考虑的问题。

简单地说，当 Brett 的任务查询工作项时，它使用的索引可能不是最新的。当然，他对 memcache 所做的锁定应该使这不太可能，因为任务的开始将阻止更多的工作项被添加到该索引。但是，如果索引更新时间足够长以至于在锁递减之前写入了一些内容，但查询结果中仍然没有返回怎么办？这样的工作项不会最终只是卡在数据存储区中，永远不会被使用吗？

Brett 的实现中是否有我没有看到的处理此问题的某些方面？显然布雷特知道他在做什么并且对此非常有信心，所以我觉得我一定错过了什么。

但是，如果不是，应该如何处理呢？

Answer 1

根据演讲日期，演讲采用了主/从数据存储。谈话是从 2010 年开始的，但是高复制 Datastore ( https://googleappengine.blogspot.com/2011/01/announcing-high-replication-datastore.html ) 直到 6 个月后才发布。

解决实体组争用的一种方法是使用类似 task-name-INDEX 的内容手动创建工作项键，并在任务中获取从 task-name-0 到 task-name-TOP_INDEX 的所有键top 索引可能会存储在 memcache 中。