Celery chord执行后Redis Pub/Sub通道未被Django释放问题排查

我来帮你分析下这个Celery chord导致Redis Pub/Sub通道残留的问题，结合你的场景和代码，整理了原因和可行的解决办法：

原因拆解 #

在你使用的Celery 4.1.1、4.2.0rc4版本中，存在一个已知的设计缺陷：当Django作为chord的发起方时，Celery会为group里的每个子任务创建celery-task-meta-chord-*格式的Pub/Sub通道，用来监听子任务的完成状态。但chord执行完毕后，Django进程持有的这些订阅连接并没有被Celery主动关闭，导致Redis里的通道一直处于被订阅的状态，只有终止Django进程才会触发Redis清理这些通道。

而且你提到杀死Celery worker对通道无影响，这也符合这个问题的特征——因为这些订阅连接是由Django进程发起并持有的，和worker进程无关。

可行的解决方案 #

1. 优先升级Celery版本 #

这个问题在Celery 4.3及以后的版本中已经被官方修复了。如果你的项目依赖允许升级，这是最省心的解决方案，升级后chord完成时会自动关闭对应的Pub/Sub连接，Redis通道也会被自动清理。

2. 手动触发连接清理（适配旧版本） #

如果暂时无法升级Celery，可以在chord执行完成后，手动清理结果后端的订阅连接。

同步场景下的清理

如果你的接口可以接受同步等待任务完成，在视图里添加清理逻辑：

from celery import current_app

# ... 启动chord的原有代码 ...

# 等待chord任务全部完成
result.get()

# 手动关闭结果后端的Pub/Sub连接
backend = current_app.backend
if hasattr(backend, '_pubsub') and backend._pubsub is not None:
    backend._pubsub.close()

异步场景下的清理

如果是异步接口，不要用get()阻塞，可以通过Celery的task_success信号来触发清理，比如在tasks.py里添加：

from celery import signals
from celery import current_app

@signals.task_success.connect(sender='post_step_2')
def cleanup_pubsub(sender=None, result=None, **kwargs):
    backend = current_app.backend
    if hasattr(backend, '_pubsub') and backend._pubsub is not None:
        backend._pubsub.close()

这样当chord的最后一个任务post_step_2执行成功时，会自动触发清理逻辑。

3. 调整Redis连接的兜底配置 #

作为兜底方案，可以在Celery配置里设置Redis连接的超时时间，让闲置的连接被自动回收：

# settings.py 或 Celery配置文件
CELERY_REDIS_MAX_CONNECTIONS = 10
CELERY_REDIS_CONNECTION_TIMEOUT = 300  # 设置为5分钟，可根据业务调整

这个方法不能从根源解决问题，但能减少残留通道的数量。

验证步骤 #

修改后可以按以下步骤验证修复效果：

• 访问/api/start/触发chord任务
• 等待所有任务执行完成（可以通过日志确认）
• 执行redis-cli pubsub channels命令，查看之前残留的celery-task-meta-chord-*通道是否已经消失

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