redis pub/sub 消息丢失是设计使然：它不持久化、无状态、无确认，仅在发布瞬间向在线客户端广播并立即释放，离线、断连或未订阅时消息直接丢弃且不可恢复。

会直接丢弃，且无法恢复——这不是故障，是 Redis Pub/Sub 的设计本质。

Pub/Sub 下线即丢消息的底层原因

Redis Pub/Sub 不维护任何消费状态：没有消息存储、不记录偏移量、不保存订阅者进度。它只是在 PUBLISH 执行瞬间，把消息拷贝一份发给所有当前 SUBSCRIBE 在线的客户端连接，然后立即释放。

• PUBLISH 返回值为 0，代表“此刻无人在线”，消息当场蒸发
• 哪怕订阅者 100ms 前刚连上又断开，这期间发布的消息也完全不可见
• PSUBSCRIBE 通配符订阅、redis-cli 重连后重新 SUBSCRIBE，都拿不到历史消息

为什么不能靠 LIST 或事务“补救”

有人尝试用 LPUSH/LRANGE 模拟队列，或在 SUBSCRIBE 前用 pipeline 读取伪队列——这些方案在并发或重连场景下极易出错：

Redis Skill - 高性能缓存管理

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

下载

• 多个订阅者同时上线时，LRANGE + DEL 非原子，消息可能被重复消费或漏消费
• PUBLISH 和 LPUSH 不在一个事务里，网络分区时会出现“消息进了队列但没广播”或反之
• LIST 无自动过期，长期积压会撑爆内存；也没 ID 序号，无法精准定位断连起始点

真正可用的离线兜底方案只有 Stream

必须放弃用 Pub/Sub 承担可靠性职责，改用 XADD + XREAD 实现持久化事件流：

• 每条消息写入前先 XADD stream:u1001 * event "xxx"，确保离线也能落盘
• 用户上线后查本地缓存的 last_id（比如存在 user:lastread:u1001），再 XREAD STREAMS stream:u1001 last_id+1
• 务必注意顺序：先 XADD，再 PUBLISH；否则网络抖动可能导致消息只广播未落库

最容易被忽略的是：Pub/Sub 和 Stream 不是二选一，而是分层协作——PUBLISH 负责秒级触达在线用户，XADD 负责兜住所有离线时段。混用时若顺序颠倒或缺少幂等校验，就会出现“用户收到了消息却没存下来”或“存了两次”的数据不一致。