Python Django中Celery无法从RabbitMQ获取任务的技术问询

嘿，我之前在做Django异步任务时也踩过Celery和RabbitMQ配合的坑，结合你这个推送数据到Android设备的场景（Django→SNS→GCM→设备），给你整理几个实打实的排查步骤，应该能帮你定位问题：

1. 先确认RabbitMQ本身没问题 #

• 先跑rabbitmqctl status看看RabbitMQ服务是不是正常运行，节点状态得是running，没有红色错误提示。
• 核对Django和Celery里的Broker配置：不管你用的是CELERY_BROKER_URL还是BROKER_URL，里面的主机、端口、虚拟主机、用户名密码必须和RabbitMQ的实际配置完全一致。比如很多人容易忽略虚拟主机的权限，要是你用了自定义虚拟主机，得先在RabbitMQ里给用户授权访问这个虚拟主机。
• 测试网络连通性：在Web应用和Celery worker的服务器上，用telnet <你的RabbitMQ主机> 5672试试能不能连上，连不上的话先搞定网络或者防火墙的问题。

2. 检查Celery Worker的启动姿势和配置 #

• 启动命令一定要对：必须是celery -A 你的Django项目名 worker -l info，这里的“你的Django项目名”要对应你项目里Celery实例所在的模块（比如根目录下的celery.py或者settings.py所在的文件夹）。别漏了-A参数，不然worker不知道用哪个配置。
• 看worker的日志：启动的时候加-l debug或者-l info，仔细看有没有连接RabbitMQ的错误。比如看到Connection refused就是网络/端口问题，Access denied就是用户名密码或者虚拟主机权限不对。
• 确认队列匹配：如果你的推送任务指定了自定义队列（比如@app.task(queue='push_queue')），那worker启动时必须加上-Q push_queue，或者在Celery配置里把这个队列加到CELERY_QUEUES里，不然worker只会监听默认的celery队列，自然拿不到任务。

3. 验证任务真的被发送到RabbitMQ了 #

• 打开RabbitMQ的管理界面（默认是http://你的RabbitMQ主机:15672），登录后看对应的队列里有没有消息堆积。如果Web应用提交任务后，队列的消息数没涨，那问题根本不在Celery，而是Django这边的任务发送逻辑有问题。
• 在Django代码里加日志：调用任务的地方，比如result = push_to_sns.delay(data)，打印一下result.id，如果没抛出异常，再去RabbitMQ里查这个任务ID对应的消息有没有存在。

4. 环境与兼容性排查 #

• 如果是用Docker部署的，得确认容器之间的网络互通，RabbitMQ的端口有没有正确映射，Celery容器能不能解析RabbitMQ的主机名（别用localhost，要用容器名或者IP）。
• 检查防火墙：确保RabbitMQ所在服务器的5672端口（AMQP协议端口）没有被防火墙拦截，不管是服务器自带的iptables还是云服务商的安全组。
• 版本兼容性：Celery和RabbitMQ的版本别差太远，比如Celery 5.x配RabbitMQ 3.8+是稳的，要是用Celery 4.x配RabbitMQ 3.10+可能会有协议不兼容的小问题。

针对你的推送场景的额外提醒 #

• 你的任务是调用SNS接口，得确保Celery worker所在的环境能访问Amazon SNS的API，AWS凭证（access key和secret key）配置正确（不管是环境变量还是配置文件）。不过这个是任务执行的问题，和“无法获取任务”无关，但如果任务执行失败被多次重试，可能会被放到死信队列，这时候也要去RabbitMQ里检查死信队列的情况。

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