多Celery同队列Worker任务重复执行问题排查求助

环境与问题概述 #

• 环境配置：
  • Celery 5.2.7、Python 3.8.10，Redis作为Broker
  • 按任务规模（小/中/大）拆分独立队列，对应专属Worker
  • 关键配置：开启late ack，prefetch_count=1，visibility_timeout设为最大值
  • Worker启动命令：celery -A celeryapp worker --concurrency=1 -Ofair -l INFO -E -Q bigtask-queue -n big@%h
• 问题现象：当有4个任务、启动4个同类型Worker时，每个任务会被4个Worker各执行一次，而非每个任务仅被一个Worker处理

核心问题排查与解答 #

1. 可能遗漏的关键配置 #

Redis作为Broker时，你当前的配置存在一个易忽略的冲突点：-Ofair选项与late ack的兼容性问题。

• -Ofair强制Worker每次仅取一个任务，但结合late ack（任务执行完成后才发送确认信号），Redis队列可能因Worker心跳异常、连接中断等问题，误将未确认的任务重新放回队列。
• 检查任务装饰器是否显式设置了acks_late=True：如果仅全局开启late ack但任务未继承该配置，等于未生效。
• 确认visibility_timeout是否设置到Redis允许的最大值（2^31-1秒），若只是设置了较大值但未达上限，可能任务未执行完就被重新标记为可见。

2. Celery是否无法识别任务已被其他Worker获取？ #

正常情况下不会。Celery+Redis通过visibility_timeout机制将已被获取的任务标记为"暂不可见"，这段时间内其他Worker无法获取该任务。出现重复执行说明该机制失效，大概率是以下原因：

• Worker进程异常退出（如OOM、强制终止），未发送任务确认信号，Redis在visibility_timeout到期后将任务重新放回队列。
• Worker与Redis的连接中断，导致"任务已被获取"的标记未被正确记录。
• 任务task_id重复：若手动指定了重复的task_id，Celery会判定为同一任务，若前一次任务未确认，会被重复调度。

3. 用Redis标记任务状态是否可行？是否存在竞态条件？ #

可行，且Redis的单线程特性可规避竞态条件：

• 实现逻辑：任务启动前，用Redis的SETNX（仅当键不存在时设置）命令标记任务为"running"，只有成功设置的Worker才执行任务；执行完成后删除标记，或为标记添加过期时间（EXPIRE），避免Worker崩溃导致任务永久无法处理。
• 竞态规避：多个Worker同时执行SETNX时，Redis仅允许一个操作成功，不会出现多Worker同时执行同一任务的情况。

4. 其他解决方案 #

• 移除-Ofair选项：-Ofair会关闭预取优化，在多Worker场景下易引发Redis队列分发逻辑异常，结合late ack时问题更明显。保留prefetch_count=1即可实现单任务单Worker处理。
• 排查任务发布逻辑：确认任务是否被重复调用/发布到队列多次——若任务本身被推送了4次，自然会被4个Worker各执行一次。
• 检查Worker队列订阅：确认所有同类型Worker是否仅订阅了目标队列（如bigtask-queue），避免因订阅错误队列导致任务被重复获取。
• 升级Celery版本：Celery 5.2.7存在Redis Broker相关的已知重复调度bug，升级到5.3.x及以上版本可能直接解决问题。

内容的提问来源于stack exchange，提问作者SagarM