Django集成Celery任务已注册但生产环境无法触发执行问题

核心问题定位 #

从配置、日志和依赖版本交叉验证，故障由4个部署层面的配置/兼容问题共同导致，开发环境因本地路径、默认配置缓存碰巧可运行，生产环境进程启动为干净环境后问题暴露：

• Celery配置加载逻辑错误
  celery.py中调用app.config_from_object('django.conf:settings')未指定namespace='CELERY'参数。Celery 4.x版本规则下，该参数缺失时会直接读取settings中与配置项同名的键，不会自动识别CELERY_前缀的配置项，除BROKER_URL外，序列化规则、时区、自动发现逻辑等配置全部未生效，生产环境下任务序列化、路由规则全部走默认值，和worker侧预期规则不匹配。
• 导包路径混乱导致任务名不匹配
  日志中存在明显的路径冲突：初始化时指定的settings模块为tax.settings，配置的手动导入任务路径为tax.tasks，但worker实际注册的任务名为taxnepal.tasks.click_example，shell中触发任务时也是从taxnepal.tasks导入。这是部署时Python搜索路径包含项目上层目录导致的同文件多导入路径问题，客户端触发任务时携带的任务标识和worker侧注册的标识完全不一致，worker收到消息也无法匹配到对应任务执行。
• Redis Broker未指定数据库编号导致队列隔离
  配置中BROKER_URL和CELERY_RESULT_BACKEND仅写了redis地址和端口，未指定末尾的数据库编号。不同版本的kombu、redis-py解析无db号的redis地址时默认选择的数据库存在差异，Django进程发任务可能写入db1，worker监听db0，两边完全不在同一个消息队列中，任务自然永远不会被消费。
• 依赖版本存在已知兼容bug
  当前使用的Celery 4.3.0搭配redis-py 3.5.3存在未修复的连接阻塞问题：redis-py 3.3+版本修改了连接池的非阻塞逻辑，会导致任务发布时卡在TCP连接握手阶段直到超时，和描述中“调用delay()一直挂起”的现象完全吻合。

修复步骤 #

按顺序修改即可恢复：

1. 修正Celery配置加载逻辑
   修改celery.py的配置加载行，补充namespace参数，同时调整自动发现任务逻辑，避免手动写导入路径出错：

from __future__ import absolute_import
import os

from celery import Celery
from django.conf import settings

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'tax.settings')
app = Celery('tax')
# 补充namespace参数，正确读取CELERY_前缀的配置
app.config_from_object('django.conf:settings', namespace='CELERY')
# 自动从所有已安装Django app中发现tasks.py，无需手动配置导入路径
app.autodiscover_tasks(lambda: settings.INSTALLED_APPS)

2. 统一全链路导包路径
   • 确认项目根包名，所有启动命令、配置、导入语句统一使用同一个包名，禁止tax和taxnepal混写。比如项目实际根目录为taxnepal，就将DJANGO_SETTINGS_MODULE改为taxnepal.settings，启动worker/beat时-A参数统一写taxnepal。
   • 删除settings.py中冗余的CELERY_IMPORTS = ('tax.tasks',)配置，自动发现逻辑会覆盖所有任务文件，手动写导入路径极易出现路径不匹配问题。
3. 明确指定Redis数据库编号
   修改settings中的Broker和结果后端配置，强制指定使用db0，避免不同客户端默认db不一致：

BROKER_URL = 'redis://127.0.0.1:6379/0'
CELERY_RESULT_BACKEND = 'redis://127.0.0.1:6379/0'

4. 降级redis-py到兼容版本
   Celery 4.3.0官方兼容的redis-py最高版本为3.2.1，执行命令降级修复连接阻塞bug：

pip install redis==3.2.1

5. 重启进程验证
   先杀掉所有残留的celery worker、beat旧进程，再按顺序重启：
   • 启动worker：celery -A <你统一后的根包名> worker -l info
   • 如需定时任务再启动beat：celery -A <你统一后的根包名> beat -l INFO
   • 进入Django shell触发测试任务，观察worker日志是否打印任务接收、执行记录即可。

快速验证技巧：如果改完仍有异常，可打开redis-cli执行MONITOR命令监听db0的实时操作，触发任务时如果看到有LPUSH命令写入celery队列但worker无响应，说明仍存在任务名不匹配问题；如果根本没有写入操作，说明Django侧Broker配置未生效，连错了Redis地址/库。

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