我目前正在寻找替换以下视频中描述的fork-join-queue的有缺陷的实现：
https://youtu.be/zSDC_TU7rtc?t=33m37s
我意识到这段视频已经有将近八年的历史了，很高兴得知做这种事情的任何潜在的新方法和更好的方法，但是现在我正专注于按照Brett的描述进行这项工作。截至目前，我眼前的情况有点混乱。
原始开发人员与Brett所做的不同之处之一是，他将特定sum_name的所有工作项放入单个实体组中。
我对Datastore还是一个相对较新的人，但是对我来说，这似乎无法实现全部目标，因为每秒将几次新实体添加到实体组中会引起争用，而这正是我们试图避免的事情批量更改。
至于为什么有人会尝试将所有工作放在一个实体组中，原始开发人员的意见很明确-他试图防止由于最终的一致性而跳过工作项。这使我真正地深入研究了Brett的实现，我很困惑，因为这似乎是Brett并未考虑的问题。
简而言之，当Brett的任务查询工作项时，它正在使用的索引可能不是最新的。可以肯定的是，他对内存缓存所做的锁定应该使其不太可能出现，因为任务的开始将阻止将更多工作项添加到该索引。但是，如果索引更新时间足够长，以至于在锁减小之前写入了一些内容，但是仍然没有返回到查询结果中，该怎么办？这样的工作项不会仅仅停留在数据存储区中而不会被消耗掉吗？
Brett的实现中有没有涉及到我所未见的方面？显然布雷特知道他在做什么，并且对此很有信心，所以我觉得我一定很想念东西。
如果没有，那么如何处理呢？
最佳答案
根据对话的日期，对话假定为主/从数据存储。谈话是从2010年开始的，但是高复制数据存储（https://googleappengine.blogspot.com/2011/01/announcing-high-replication-datastore.html）直到6个月后才发布。
解决实体组争用的一种方法是使用类似于task-name-INDEX的东西手动创建工作项密钥，然后在任务中获取从task-name-0到task-name-TOP_INDEX和最高索引的所有密钥。可能可以存储在内存缓存中。