Redis PubSub 订阅断线后能补回消息吗

平时开发用Redis的PubSub做消息通知、事件广播这类功能的时候，难免碰到客户端网络闪断、进程临时重启的情况，不少人会好奇等连接恢复之后，之前断线期间漏掉的消息能不能自动补回来？原生的实现逻辑下是做不到的，丢消息是默认行为。

Redis 原生 Pub/Sub 没有设计消息持久化、离线堆积的能力，只要订阅客户端断开连接，这段时间内发布端推送的所有消息都会直接被丢弃，客户端后续重连成功之后也不会主动补发历史消息，只能收到重连完成之后新发布的内容。

如果订阅者在 Redis Pub/Sub 投递期间断开连接，消息不能靠重新 SUBSCRIBE 补回来。Pub/Sub 采用至多一次投递：Redis 把消息推给当时在线且已订阅的客户端后，不建立可供客户端回放的消息队列。重连能恢复“以后”的通知，却不会恢复“刚才”的历史。

只要业务允许漏掉断线期间的刷新通知，Pub/Sub 就够用；只要消息必须补读、确认或重试，就应把事件写入 Redis Streams，必要时再用 Pub/Sub 做低延迟提醒。

为什么重连后的 PubSub 没有历史消息

Pub/Sub 的模型是发布者和订阅者解耦：发布者只把载荷发送到频道，Redis 不关心当时有多少消费者，也不为某个消费者保存待确认列表。官方文档把它定义为 at-most-once delivery，也就是消息至多送达一次；网络断开或客户端处理失败时，消息会永久丢失。

因此，下面的重连代码只能修复连接状态，不能改变投递语义：

# 订阅端重连后只恢复后续通知，不会读取断线期间的历史
redis-cli SUBSCRIBE order.updated

# 发布端发送一次；此刻没有在线订阅者时，不会留下待补消息
redis-cli PUBLISH order.updated '{"id":42,"state":"paid"}'

还要注意，频道不属于 Redis 的 key space，切换数据库编号也不会形成隔离或历史记录。生产环境可以给频道加上 prod:、staging: 等前缀，但这只是命名隔离，不是消息持久化。

重连策略应该修复什么，而不是承诺什么

客户端重连后应该重新执行订阅、恢复心跳，并把收到的事件设计成幂等更新。例如刷新缓存或查询订单当前状态时，可以把消息当作“有变化的提示”，再次读取业务存储得到最终状态。这样即使同一通知重复到达，也不会重复扣库存或重复发货。

如果业务要求“每一条事件都被看到”，就不要把 Pub/Sub 的频道当队列。可用下面的 Streams 写入方式保存事件：

# 事件先落入 Stream，* 由 Redis 生成单调递增的消息 ID
XADD order.events * order_id 42 state paid

# 消费组从上次确认的位置继续读取；0-0 仅用于首次建立示例
XGROUP CREATE order.events order-workers 0-0 MKSTREAM
XREADGROUP GROUP order-workers worker-a COUNT 10 BLOCK 5000 STREAMS order.events >

消费者成功完成业务动作后再 XACK。如果进程在处理后、确认前崩溃，消息会留在待处理列表中，之后可以用 XPENDING 和 XCLAIM（或对应客户端封装）接管。这里的“至少一次”意味着业务处理必须有幂等键，不能把重复投递当成绝不会发生。

需要补消息时为什么要换 Redis Streams

常见的稳妥组合是“双通道”：写入事件时先把完整业务事件放进 order.events，再发布一个轻量的 order.updated 通知。在线页面订阅 Pub/Sub 后可以立即刷新；服务重启或发现同步游标落后时，则从 Streams 按最后成功的 ID 追赶。

两条通道不是天然原子操作，所以不要把 Pub/Sub 的成功视为事件已经可靠保存。更安全的方式是以 Streams 为事实来源，Pub/Sub 只承担加速唤醒；或者使用一个可靠写入路径，由消费者负责发送刷新通知。跨进程写入时还要定义失败补偿、事件唯一 ID 和最终状态查询。

部署前可以用这三个问题做最小验证

第一，明确断线期间漏掉的是“提示”还是“事实事件”；如果是后者，直接改用 Streams。第二，为消费者保存最后确认的消息 ID，并让业务操作携带事件 ID 做幂等。第三，模拟订阅端停机后发布一条消息，再重连观察：Pub/Sub 不应出现历史补发，而 Streams 应能从保存的 ID 读取到事件。这个验证关注的是语义，不是把偶然收到的重连消息误判成可靠机制。

所以，Redis PubSub 订阅断线后不能补回已经错过的消息；要补消息，必须在发布时选择带持久化和消费位点的 Streams，或者把 Pub/Sub 限定为可靠事件之外的即时通知层。

相关问题

重连后重新订阅会不会重复收到消息？不会补发断线历史，但如果应用同时订阅频道和匹配同一频道的模式，在线期间可能收到两份消息，应避免重复处理。

Redis Streams 能保证业务只执行一次吗？不能直接保证。消费组支持确认和失败接管，但崩溃恢复可能带来重复处理，仍需使用幂等键和可重试的业务逻辑。