【发布时间】:2020-06-10 20:32:52
【问题描述】:
我正面临这个奇怪的问题。我的一些 (5%) celery 任务被默默地放弃了。
在 celery 日志中进行了一些挖掘,我发现在某些情况下,会为不同的任务生成相同的任务 ID。自然,任何新任务都会覆盖具有相同任务 ID 的现有任务;导致旧任务静默删除(如果未执行)。
在 1.5 小时内,相同的 UUID 生成了 3 次。我做了一些随机抽样,结果在同一台机器上出现了这种情况,时间跨度很短(1-2 小时)。服务器每天生成大约 100 万个 UUID。一个 7 位的小数与 38 位的数字相比 - 可能的 UUID 的数量。
我在 Linux VM 上运行 python 3.6 和 celery 4.4.2。
Celery使用python的uuid.uuid4:Reference
我不知道如何从这里开始。 python 版本(或 linux 内核)中是否存在错误、某些配置问题或硬件/VM 错误? 所有情况似乎都不太可能。
更新:
VM 是运行 ubuntu 18 LTS 的标准 Google Cloud Platform 计算实例。
【问题讨论】:
-
有趣。
uuid4just callsos.urandom的字节来源,所以我猜这是一个特定于平台的随机性问题? -
你有任何关于虚拟机如何与底层硬件交互的细节吗?我很好奇在这样的设置中随机性实际上来自哪里。
-
@bnaecker 我在我的问题中添加了更多信息
-
人们过去曾见过 uuid4 冲突 (github.com/ramsey/uuid/issues/80),但在这种特殊情况下得出的结论是这是系统问题
-
您的可见性超时时间是多少?
标签: python google-cloud-platform celery uuid