Celery Worker为何消费未监听的low_prio队列？

你遇到的这种情况，通常由以下几种原因导致：

1. 存在未终止的旧Worker进程 #

你启动了指定监听high_prio队列的新Worker，但之前监听low_prio队列的Worker进程没有完全终止，仍在后台运行。实际处理任务的是旧Worker，而你误以为是新Worker执行的。

可以通过进程管理工具（如ps aux | grep celery）检查当前运行的Celery Worker进程，确认是否有多余的Worker在监听low_prio队列。

2. Worker启动参数未生效 #

虽然你使用了--queues=high_prio参数，但可能因以下原因导致参数未生效，Worker仍然默认监听low_prio队列：

• 命令拼写错误：检查是否误写参数（比如写成--queue而非--queues）；
• Celery版本兼容问题：部分旧版本Celery对长参数--queues支持不佳，可尝试用短参数-Q替代，启动命令改为：

  celery -A myapp -Q high_prio
  

• 启动日志验证：查看Worker启动时的日志输出，确认日志中是否明确显示Listening on queues: high_prio，如果显示的是默认队列，说明参数未生效。

3. 队列路由配置存在绑定规则 #

如果你的Celery应用中配置了task_queues，且high_prio队列绑定了low_prio的路由键，那么发送到low_prio路由键的任务会被路由到high_prio队列中。此时Worker监听high_prio队列就能收到该任务，而任务自身的routing_key仍然是low_prio（这就是你看到输出为low_prio的原因）。

比如类似这样的配置会导致该情况：

from celery import Queue

app.conf.task_queues = [
    Queue('high_prio', routing_key='low_prio'),
]

4. 任务提交时的隐性路由 #

虽然你调用move.apply_async()时未指定队列，但如果存在全局的task_routes配置，可能将move任务路由到了high_prio队列，但任务的routing_key仍保留默认的low_prio。不过这种情况较少见，除非你在配置中明确设置了类似规则。

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