达到 eta 时，长 eta（8 小时以上）的 celery 任务会连续执行多次

Posted 2023-02-24

【中文标题】达到 eta 时，长 eta（8 小时以上）的 celery 任务会连续执行多次

【英文标题】：celery tasks with long eta (8+ hours) are executed multiple times in a row when eta is reached

【发布时间】：2012-09-22 21:48:12

【问题描述】：

我正在创建一个 eta 介于 3 到 20 小时之间的任务，当我查看工作人员日志时，对于这个任务，工作人员在收到原始任务后每小时都会说“Got task from broker: ...”，直到 eta 达到到达。

我知道这与设置 BROKER_TRANSPORT_OPTIONS = 'visibility_timeout': X 有关，其中 X 是以秒为单位的数字。

所以我使用了 visibility_timeout，如果我将其设置为小于 1 小时，那么我可以看到工作人员每 X 秒执行一次相同的任务，但是当我将 visibility_timeout 设置为 X 大于 1 小时时，它无论我设置的时间如何，都默认为 1 小时。

还有其他人遇到这个问题吗？这是一个已知的错误吗？

我正在使用 Celery 3.0.11（Chiastic Slide） 使用 Redis 服务器版本 2.4.15

【问题讨论】：

我刚刚也遇到了这个错误，在 Redis 服务器 v.2.4.6 上运行 Celery v.3.0.19，但即使在与 Redis 服务器在同一台机器上运行的工作人员也会发生这种情况。

也观察到了。 celery==3.0.21 django-celery==3.0.21 Python 2.7.3，Redis 服务器版本 2.2.12。 .在同一台机器上运行。

在 celery 3.1.17、Redis 服务器 2.8.4 中也遇到了这个错误，即使 Redis 和 worker 在同一台机器上运行也是如此。

也经历过这个celery==4.3.0,redis==3.2.1,Redis server v=6.0.9，一个小时后我安排了12个任务而不是1个。我在本地单机上运行它

【参考方案1】：

编辑：任何使用 kombu* 的消息消费者都连接到同一个 Redis URL 将有助于恢复未确认的消息，因此您必须确保所有这些消息 配置了相同的visibility_timeout 值。

一个常见的错误是像这样启动 Flower 监视器：

celery flower -b redis://somewhere

而不是这样：

celery -A proj flower

因为前者意味着不会配置花实例 使用 celery 配置，然后缺少 BROKER_TRANSPORT_OPTIONS 和 visibility_timeout 设置。

除此之外，您还必须确保挂钟 使用 ntp 进行同步，如下面的原始回复所述。

kombu 是 Celery 使用的消息传递库。

原始回复：

尽管我没有听说过这样的事情，但它可能是一个错误。 我向kombu/transport/redis.py 添加了一些打印语句，以检查visibility_timeout 是否设置正确，这绝对适合我。测试它是否适用于大于一小时的值将需要更多时间（确切地说大约需要 2 小时），所以我可以在那时报告。

同时，您可以通过自己添加 print 语句来验证您是否正确设置了 visiblity_timeout（例如，添加到 redis 传输中的 restore_visible 方法）

请注意，此功能使用时间戳，因此如果您拥有多台机器，重要的是时钟几乎同步（尤其是不偏离小时）。 您应该始终在联网服务器上使用 ntp 并定期同步。

【讨论】：

我检测了kombu/transport/redis.py 并且visibility_timeout 确实设置正确。将 redis 服务器和 celery worker 移动到单机解决了这个问题。我检查了以前的机器，它们是同步的（例如，两者的系统时间和日期是相同的）

用新的细节更新了答案！