Redis Pub/Sub 不适合作为消息队列，因其本质是无状态内存广播模型，不保证消息可达、无持久化、无消费确认、无历史回溯、断连或重启即丢失全部消息，仅适用于允许丢失的实时轻量通知场景。

PUBSUB 不适合作为消息队列，因为它根本就不是队列——它只是内存里的广播喇叭，一喊就散，没人管收没收到。

消息丢了不报错，PUBLISH 返回成功不代表投递成功

PUBLISH 命令返回的数字是「当前在线订阅者数量」，不是「已送达数量」。如果返回 0，说明此刻没人在线，那这条消息就直接蒸发了，Redis 不存、不记、不补。

• 发布时没有订阅者 → 消息立即丢弃，后续再连也收不到
• 订阅者网络抖动断开几秒 → 断连期间所有消息永久丢失
• Redis 进程重启 → 所有频道状态清空，PUBSUB CHANNELS 返回空，不是没频道，是整个订阅关系没了

没有消费确认，PSUBSCRIBE 收到即算完成

和 RabbitMQ 的 basic.ack 或 Kafka 的 offset 提交不同，Redis 的 PSUBSCRIBE 一收到消息就完事，不等你处理完，也不管你是否崩溃。

Redis Skill - 高性能缓存管理

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

下载

• 消费者解析失败、写 DB 失败、进程被 kill —— Redis 完全不知情，不会重发
• 想实现“至少一次”，得自己在业务层记日志 + 幂等判断，成本远高于直接用专业 MQ
• 没有 unack 状态，没有重入队机制，也没有死信通道

无法回溯、无法积压、无法限流

PUBSUB 是纯推模型，没有存储层，也就没有消息生命周期管理能力。

• 订阅后才能收消息，之前发的全不可见 —— 不支持历史消息拉取
• 没有 backlog 概念，高并发瞬时消息洪峰会直接打满 client-output-buffer-limit，触发强制断连（尤其旧版 Redis）
• 集群模式下，PUBLISH 只在当前节点广播，跨节点频道不互通，必须用单节点或代理层兜底

替代方案：别硬扛，换更合适的工具

如果你已经写了 pubsub.subscribe() 却发现线上总丢支付通知或订单事件，不是代码问题，是模型选错了。

• 需要持久化 + ACK + 重试 → 直接上 RabbitMQ 或 Kafka
• 想继续用 Redis → 改用 Streams（XADD/XREADGROUP），它支持消费者组、pending list、ACK 和历史读取
• 极轻量实时通知（如在线状态广播、聊天室刷屏）→ PUBSUB 才真正匹配它的设计边界

真正容易被忽略的点是：很多人把「能发能收」当成「可用」，但消息队列的可靠性不在通路，而在责任归属——谁来保证消息不丢、不错、不重。Redis 把这个责任完全甩给了客户端，而生产系统里，最不可靠的恰恰就是客户端。