我目前正在寻找替换以下视频中描述的有缺陷的 fork-join-queue 实现:
https://youtu.be/zSDC_TU7rtc?t=33m37s
我意识到这个视频已经有将近八年的历史了,我很乐意学习任何潜在的新的和更好的方法来做这些事情,但现在我正专注于尝试按照描述的方式完成这项工作布雷特。目前,摆在我面前的有点乱。
原始开发人员与 Brett 不同的地方之一是,他将特定 sum_name
的所有工作项放入单个实体组中。
我对数据存储还比较陌生,但对我来说这似乎违背了整个目的,因为每秒多次向实体组添加新实体会引起争用,而这正是我们正在尝试的事情通过批处理更改来避免。
至于为什么有人会尝试将所有工作放在一个实体组中,原始开发人员的评论很明确——他试图防止工作项因最终一致性而被跳过。这让我真正深入研究了 Brett 的实现,我感到非常困惑,因为这似乎是 Brett 没有考虑的问题。
简单地说,当 Brett 的任务查询工作项时,它使用的索引可能不是最新的。当然,他对 memcache 所做的锁定应该使这不太可能,因为任务的开始将阻止更多的工作项被添加到该索引。但是,如果索引更新时间足够长以至于在锁递减之前写入了一些内容,但查询结果中仍然没有返回怎么办?这样的工作项不会最终只是卡在数据存储区中,永远不会被使用吗?
Brett 的实现中是否有我没有看到的处理此问题的某些方面?显然布雷特知道他在做什么并且对此非常有信心,所以我觉得我一定错过了什么。
但是,如果不是,应该如何处理呢?
最佳答案
根据演讲日期,演讲采用了主/从数据存储。谈话是从 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 中。
关于google-app-engine - 如何处理 fork-join-queue 中的最终一致性,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/48914036/