我目前正在寻找替换以下视频中描述的fork-join-queue的有缺陷的实现：
https://youtu.be/zSDC_TU7rtc?t=33m37s
我意识到这个视频已经有近8年的历史了，我很高兴能够了解任何潜在的新的更好的方法来做这些事情，但是现在我正专注于尝试按照描述进行这项工作布雷特。截至目前，在我面前的是有点混乱。
原始开发人员与Brett的不同之处在于他将特定sum_name的所有工作项放入单个实体组中。
我对数据存储区来说还是比较新的，但对我而言似乎打败了整个目的，因为每秒多次向实体组添加一个新实体会引起争用，这就是我们正在尝试的事情。通过批量修改来避免。
至于为什么某人会尝试将所有工作放在一个实体组中，原始开发人员的评论很明确 - 他试图阻止工作项因最终的一致性而被跳过。这让我真正深入研究了Brett的实现，我非常困惑，因为它看起来似乎是Brett没有考虑的问题。
简单地说，当Brett的任务查询工作项时，它使用的索引可能不完全是最新的。当然，他使用memcache进行的锁定应该不太可能，因为任务的开始将阻止更多的工作项被添加到该索引中。但是，如果索引更新时间足够长，以便在锁定减少之前写入某些内容，但仍未在查询结果中返回，该怎么办？这样的工作项目不会只是挂在数据存储区中，永远不会消耗掉吗？
Brett的实施是否有一些方面可以解决这个我没有看到的问题？很明显，布雷特知道他在做什么，并对此非常有信心，所以我觉得我一定会错过一些东西。
如果没有，那怎么可能会处理这个呢？
答案 0 :(得分：3)
根据谈话的日期，谈话假定主/从数据存储。该演讲是从2010年开始的，但高复制数据存储（https://googleappengine.blogspot.com/2011/01/announcing-high-replication-datastore.html）直到6个月后才发布。
实体组争用的一种方法是使用task-name-INDEX之类的东西手动创建工作项密钥，并在任务中获取从task-name-0到task-name-TOP_INDEX的所有密钥和top索引可能存储在memcache中。
答案 1 :(得分：2)
我认为关于散列的一点是他如何避免这种情况，以及在Bigtable中分配负载＆＃39;并避免写入同一行开头的所有工作条目＆＃39;：https://youtu.be/zSDC_TU7rtc?t=48m40s
即使不是这样，他对Datastore内部运作的部落知识确实似乎在这里发挥作用。
您可以让您的任务启动另一项任务，该任务会在10秒后执行完整性检查。
他实际上确实提到，如果您有一个有损数据模型，那么离线工作会获取丢失的任何数据。 https://youtu.be/zSDC_TU7rtc?t=48m40s