<p>Redis Pub/Sub 不能用作 Celery 的 result_backend，因其不支持随机读写、无过期机制、无法按 task_id 查询，Celery 调用 GET celery-task-meta-* 会报错或超时；它仅适合事件广播，应与 result_backend 分离部署。</p>
Redis Pub/Sub 不能用作 Celery 的 result_backend
Celery 的 result_backend 要求支持「随机读写 + 过期控制 + 原子状态更新」，而 Redis Pub/Sub 是纯消息广播通道：它不存储数据、无法按 task_id 查询、没有 TTL 机制、也不支持 GET/SET/EXPIRE 操作。你调用 AsyncResult(task_id).get() 时，Celery 会尝试从 backend 执行 GET celery-task-meta-<task_id></task_id>，Pub/Sub 根本不响应这类命令，直接抛出 redis.exceptions.ResponseError: WRONGTYPE Operation against a key holding the wrong kind of value 或更常见的连接超时/空响应。
为什么有人误以为能用 Pub/Sub 替代 Backend
混淆通常来自两个地方：
- 把「任务状态推送」当成「结果存储」：有人在 task 内部用
redis.publish('task_progress', json.dumps({...}))推进度，但这只是业务侧主动通知，Celery 自身完全 unaware，AsyncResult无法感知； - 看到
redis-py支持PUBSUB就以为 Celery 可配置backend='redis+pubsub://...'—— 实际上 Celery 官方和社区所有 backend 实现（包括celery/backends/redis.py）都只使用 Redis 的键值命令，redis://URL 中的db参数指向的是数据库编号，不是 Pub/Sub 频道。
硬要 hack 会遇到什么问题
即使绕过 Celery 限制、自己实现一个基于 Pub/Sub 的 backend 类，也会立刻撞上三座墙：
-
无状态不可查：Pub/Sub 消息一发即逝，没被订阅者实时收到就丢，
AsyncResult(task_id).state永远是PENDING； -
无过期机制：无法设置
result_expires，没法自动清理旧任务元数据，内存泄漏比默认 Redis backend 更严重； -
不支持阻塞等待：
.get(timeout=30)依赖 backend 的轮询或监听能力，但 Pub/Sub 的listen()是单向流式，无法绑定到某个特定task_id上做条件等待。
真正该用 Pub/Sub 的地方
它适合做「轻量级事件广播」，和 result_backend 并行存在、各司其职：
立即学习“Python免费学习笔记（深入）”；
- 前端轮询变长连接：Worker 在任务执行中 publish
{'task_id': 'xxx', 'progress': 65, 'status': 'PROGRESS'}，前端用 SSE 或 WebSocket 订阅； - 跨服务通知：比如导出完成时，publish
csv_exported事件，触发下游邮件服务或缓存刷新； - 注意别和 result_backend 写同一个 DB：建议
broker_url='redis://localhost:6379/0'，result_backend='redis://localhost:6379/1'，Pub/Sub 用db=2或干脆独立 Redis 实例，避免 KEYS 扫描干扰。
真正麻烦的不是技术能不能跑通，而是团队里有人开始写 redis.from_url(...).publish() 来“替代” result_backend，结果排查 AsyncResult 一直返回 PENDING 时，得先翻源码确认 Celery 根本没走那条路——这种隐性耦合，比内存涨到 90% 还难定位。
