Redis Pub/Sub 断线后消息为什么不能补收

Redis Pub/Sub 断线后不能补收，不是客户端少调用了一次重试，而是它本来就没有消息历史。发布者执行 PUBLISH 时，Redis 只把消息推给当下仍连接并订阅频道的客户端；订阅连接在网络断开期间错过的内容，重连后不会自动补发。需要“上线后把漏掉的订单事件补回来”，应使用 Redis Streams；只需要把刷新提示、缓存失效通知广播给在线实例，Pub/Sub 才合适。

Pub/Sub 的断线窗口为什么无法补收

Pub/Sub 的频道更像一条连接上的广播线，而不是日志。下面这组最小命令适合说明语义，两个终端分别执行订阅和发布：

# 终端 A：建立实时订阅连接
redis-cli SUBSCRIBE orders

# 终端 B：只向当前在线的 orders 订阅者广播
redis-cli PUBLISH orders '{"order_id":"A1001","status":"paid"}'

如果终端 A 在发布前已经断开，PUBLISH 不会替它排队；它稍后重新执行 SUBSCRIBE orders，只能收到之后的新消息。Redis 官方把这种语义定义为 at-most-once：消息至多送达一次，订阅端因错误或网络断开而没接住时，消息就丢失了。

先排查连接状态，再判断是不是选错模型

遇到“偶尔收不到”时，先不要把同一条消息在客户端缓存里重放。按下面的层次核对，通常很快能区分连接问题和产品语义问题：

一个实用判断是：即使通知丢了，消费者能否通过读取数据库或 Redis Key 得到最终状态？如果能，Pub/Sub 通常只是“提醒重新读取”；如果不能，丢一次通知就会造成业务事实缺口。

需要补收时为什么要换成 Streams

Streams 把事件写成带 ID 的追加条目，消费者可以按游标读取已经存在的内容。最小的消费组示例如下：

# 写入带业务字段的事件，* 由 Redis 生成条目 ID
redis-cli XADD orders:events '*' order_id A1001 status paid

# 创建消费组；同一组只需初始化一次
redis-cli XGROUP CREATE orders:events order-workers 0 MKSTREAM

# 读取尚未交给本组消费者的新消息
redis-cli XREADGROUP GROUP order-workers worker-1 COUNT 10 BLOCK 5000 STREAMS orders:events '>'

# 业务处理成功后确认；未确认条目会留在待处理列表
redis-cli XACK orders:events order-workers 0-0

示例里的 0-0 只是占位写法，实际使用时应替换为返回结果中的真实条目 ID。断线后，消费组仍保留已投递但未确认的状态；恢复逻辑可以先查 XPENDING，再用 XCLAIM 或 XAUTOCLAIM 接管超时未完成消息。若只是想补读一段历史，也可以用 XRANGE 或不带消费组的 XREAD 按 ID 读取。

用业务后果选择 Pub/Sub、Streams 还是混合方案

两种结构不是“谁性能更高”的简单替代关系，核心是消息是否需要成为可追溯事实：

• 选 Pub/Sub：在线刷新、缓存失效、服务发现提示等场景。消费者收到通知后应重新读取真实状态，不能把通知本身当作唯一数据。
• 选 Streams：订单状态、支付结果、审计事件、任务处理等需要补收、确认、重试或按时间范围回放的场景。
• 混合使用：先用 Stream 记录不可丢的事件，再发布一条轻量 Pub/Sub 通知让在线实例尽快刷新。即使广播丢失，消费者仍可从 Stream 或业务存储恢复。

Stream 也不是无限历史仓库。用 XTRIM 或 XADD ... MAXLEN 设定保留窗口，并把窗口长度和最长离线时间、补偿流程一起设计。若业务要求多年审计，Redis 只适合作为近期缓冲，还应把事件落到更适合长期保存的系统。

常见问题

重连后再次 SUBSCRIBE 能拿到最后一条消息吗？

不能。SUBSCRIBE 只建立新的实时订阅，不携带历史游标。

把 Pub/Sub 消息同时写进 List 能补收吗？

可以自行设计，但要处理写入原子性、消费确认、重复和清理；如果这些能力是核心需求，优先评估 Streams。

Streams 消费组能保证绝不重复吗？

不能把它理解成绝不重复。消费组支持确认和失败接管，重试可能再次投递，因此业务处理最好按事件 ID 做幂等。

只做缓存失效通知也要换 Streams 吗？

通常不用。只要丢通知后读取真实 Key 仍能得到正确状态，Pub/Sub 的实时广播语义正好匹配。

最终检查只问一句：消费者断线几分钟后，系统是否必须知道这段时间发生过哪些事件？不需要，就把 Pub/Sub 当通知；需要，就让事件先拥有可读取的历史，再谈实时广播。