redis pub/sub 不适合异步任务处理，因其无确认机制、无持久化、不支持消费者组与积压缓冲；应选用lpush+brpop或xadd+xreadgroup（stream）实现可靠任务队列。

Redis 的 Pub/Sub 不适合做异步任务处理，它不是任务队列，强行用会丢消息、难监控、无法重试。

为什么 PUBSUB 不能替代任务队列

根本原因在于设计目标不同：PUBSUB 是为广播通知设计的，不是为任务交付设计的。

• 没有消费者确认机制 —— 消息发出即丢，订阅者掉线或处理失败，消息直接蒸发
• 无持久化 —— Redis 进程重启、频道无人订阅时，所有未消费消息全部丢失
• 不支持消费者组或负载均衡 —— 所有订阅者收到同一份消息，无法分摊任务
• 无积压缓冲 —— 频道内部无队列结构，发布速度 > 订阅消费速度时，旧消息被新消息覆盖（取决于底层实现和缓冲区）

LPUSH + BRPOP 或 Stream 才是正经任务队列方案

真正用于异步任务（如发邮件、生成报表、扣减库存）时，必须选有状态、可追溯的数据结构。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• LPUSH + BRPOP：简单可靠，支持多消费者争抢，但无消息重试、无历史追溯
• XADD + XREADGROUP（Stream）：支持消费者组、ACK 确认、未处理消息重投、消息历史可查，接近专业 MQ 行为
• 注意 Stream 的 MAXLEN 设置 —— 不设限可能撑爆内存；设太小又丢历史，建议按业务保留 24–72 小时数据

什么场景下才该用 PUBSUB

只适用于「丢了也不关键」+「要快」+「所有人同时知道」的轻量通知。

• 实时聊天室在线状态广播（用户上线/下线）
• 服务健康心跳透传（比如某个 API 实例主动推送自己已就绪）
• 开发环境日志聚合（多个进程往同一频道打 debug 日志，本地监听看）
• 千万别用在支付回调、订单创建、短信发送这类需要至少一次交付的链路里

真正落地时，最容易被忽略的是：你以为自己在用「队列」，其实只是开了个广播喇叭。等线上开始丢任务，再切到 Stream，就得补 ACK 逻辑、重写消费者、处理堆积消息 —— 这些都得在最初选型时想清楚。