几天后,我的芹菜服务将无限期地一遍又一遍地重复任务。这有点难以复制,但每周定期发生一次或更频繁地发生,具体取决于正在处理的任务量。
我将非常感谢有关如何获取有关此问题的更多数据的任何提示,因为我不知道如何跟踪它。当它发生时,重新启动芹菜会暂时解决它。
我有一个芹菜节点运行4个工人(版本3.1.23)。经纪人和结果后端在Redis上。我只发布到一个队列,我不使用芹菜节拍。
Django的setting.py中的配置是:
BROKER_URL = 'redis://localhost:6380'
CELERY_RESULT_BACKEND = 'redis://localhost:6380'
日志的相关部分:
[2016-05-28 10:37:21,957: INFO/MainProcess] Received task: painel.tasks.indicar_cliente[defc87bc-5dd5-4857-9e45-d2a43aeb2647]
[2016-05-28 11:37:58,005: INFO/MainProcess] Received task: painel.tasks.indicar_cliente[defc87bc-5dd5-4857-9e45-d2a43aeb2647]
[2016-05-28 13:37:59,147: INFO/MainProcess] Received task: painel.tasks.indicar_cliente[defc87bc-5dd5-4857-9e45-d2a43aeb2647]
...
[2016-05-30 09:27:47,136: INFO/MainProcess] Task painel.tasks.indicar_cliente[defc87bc-5dd5-4857-9e45-d2a43aeb2647] succeeded in 53.33468166703824s: None
[2016-05-30 09:43:08,317: INFO/MainProcess] Task painel.tasks.indicar_cliente[defc87bc-5dd5-4857-9e45-d2a43aeb2647] succeeded in 466.0324719119817s: None
[2016-05-30 09:57:25,550: INFO/MainProcess] Task painel.tasks.indicar_cliente[defc87bc-5dd5-4857-9e45-d2a43aeb2647] succeeded in 642.7634702899959s: None
任务由用户请求发送:
tasks.indicar_cliente.delay(indicacao_db.id)
以下是source code of the task和celery service configuration。
为什么在服务运行一段时间后多次收到任务?我怎样才能获得一致的行为?
答案 0 :(得分:1)
使用rabbitmq broker代替redis解决。
答案 1 :(得分:0)
可能有点过时了,但是我也遇到了同样的问题,并使用Redis进行了修复。长话短说,Celery等待一段时间执行任务,如果时间已到,它将重新启动任务。这称为可见性超时。 来自文档的解释:
如果在“可见性超时”中未确认任务,则该任务 将重新交付给其他工作人员并执行。这引起 ETA /倒数/重试任务的问题,执行时间 超过可见性超时;事实上,如果发生这种情况 再次执行,并再次循环执行。所以你必须增加 可见性超时,以匹配您最长的预计到达时间 计划使用。请注意,芹菜将在工作人员处重新传递消息 关闭,因此可见性超时时间长只会延迟 在断电或发生故障时重新传送“丢失的”任务 强制解雇工人。
选项示例:http://docs.celeryproject.org/en/latest/userguide/configuration.html#broker-transport-options
详细信息: http://docs.celeryproject.org/en/latest/getting-started/brokers/redis.html#visibility-timeout
答案 2 :(得分:0)
我遇到了这样的问题。提高芹菜 visibility timeout 不起作用。
事实证明,我还运行了一个 Prometheus 导出器,该导出器实例化了自己的 Celery 对象,该对象使用默认的可见性超时——因此取消了我在应用程序中放置的更高的超时。
如果您有多个 Celery 客户端——无论它们是用于提交任务、处理任务还是仅仅观察任务——请确保它们都具有完全相同的配置。