Redis PUB/SUB断网后无法接收历史消息，因其是内存广播、不落盘、不重试；需改用Stream实现消息持久化、可重放与ACK机制。
发布订阅在断网后收不到历史消息，这是设计使然，不是bug
Redis 的 PUB/SUB 本质是内存级广播，不落盘、不重试、不回溯。一旦客户端断连（比如网络分区期间掉线），它就彻底“失联”——重连后不会自动补发断连期间的 PUBLISH 消息，哪怕只断了1秒。这不是配置问题，是模型决定的：SUBSCRIBE 建立的是长连接通道，通道断了，中间的消息就丢了。
- 典型现象：订阅者进程重启或网络抖动后，
SUBSCRIBE news成功，但之前发布的PUBLISH news "alert"永远收不到 - 别试图用
CLIENT LIST查“离线订阅者”——Redis 根本不维护这种状态 - 如果你需要“至少一次投递”或“消息可追溯”，
PUB/SUB不适合，该换Stream
客户端重连时必须重新 SUBSCRIBE，且不能依赖旧连接句柄
很多客户端库（如 redis-py）的默认行为是自动重连 TCP，但**绝不会自动重订频道**。重连后若不显式执行 SUBSCRIBE，连接看似正常，实则处于“空订阅”状态——收不到任何消息，也不报错。
- 正确做法：监听客户端的
on_disconnect/on_reconnect事件，在重连成功回调里调用SUBSCRIBE（注意：不是PSUBSCRIBE，除非你本来就是模式订阅） - 错误写法示例（伪代码）：
client = Redis() # 自动重连开启<br>client.subscribe("log") # 只在初始化时调一次<br># 断网恢复后，这行不会自动重跑 - 更稳妥的做法：每次
PUBLISH前，用PUBSUB NUMSUB log检查当前订阅数；若为0，说明可能已失联，主动重建订阅
网络分区下多实例部署时，避免“脑裂式重复消费”
当你的服务有多个 worker 实例都订阅同一个频道（例如 task_queue），而它们之间又因网络分区被割裂，就可能出现多个实例各自认为自己是“唯一活跃订阅者”，导致同一条 PUBLISH 被重复处理多次。
- 根本原因：Redis 不提供订阅者去重或选主机制，
PUB/SUB是纯广播，所有在线订阅者无差别收消息 - 缓解方式：在业务层加幂等控制，比如用
SET task:123 done EX 3600 NX标记任务ID已处理，失败则跳过 - 不要依赖
UNSUBSCRIBE清理——分区时它可能发不出去；也不要靠心跳踢下线——Redis 不暴露订阅者存活状态
真要保障消息完整性？直接弃用 PUB/SUB，改用 Stream + consumer group
如果你的需求里包含“消息不丢”“可重放”“支持 ACK”“允许离线消费”，那继续折腾 PUB/SUB 的重连逻辑就是在对抗设计初衷。Redis 5.0+ 的 Stream 才是为此而生：
-
XADD logs * level "error" msg "timeout"写入带序号的消息 -
XGROUP CREATE logs mygroup $ MKSTREAM创建消费者组 - 每个 worker 用
XREADGROUP GROUP mygroup worker1 COUNT 1 STREAMS logs >拉取未处理消息 - 处理完必须
XACK logs mygroup <id>，否则会重推（PEL 列表保障） - 哪怕 worker 宕机，其他成员也能从 PEL 继续消费，消息不丢失
网络分区对 Stream 的影响仅限于单节点不可用时的写入延迟，只要集群或哨兵能切主，消息序列号和消费者组状态就能延续——这点比 PUB/SUB 高出不止一个量级。
