redis cluster的subscribe连接在故障转移时必然中断，因其绑定特定master节点且gossip不传播订阅状态，客户端需主动重连并重新订阅，无法自动补偿。
会丢失，且无法靠集群自动补偿——这是 Redis Cluster + Pub/Sub 的固有缺陷，不是配置能绕过的。
为什么故障转移时 SUBSCRIBE 连接必然中断
Redis Cluster 的 SUBSCRIBE 是纯内存长连接，绑定在某个 master 节点上；一旦该节点被踢出集群（如主从切换、网络分区），TCP 连接立即失效，客户端收不到任何错误提示，只是“静默失联”。PUBLISH 命令若发到旧 master（或已下线节点），直接返回 (integer) 0，消息当场蒸发。
- 订阅者不会自动重连到新主节点——gossip 协议不传播订阅状态
- 客户端没监听
+switch-master事件，就无法感知地址变更 - 即使重连成功，也必须手动重新执行
SUBSCRIBE channel_a channel_b，否则频道监听完全空白
Sharded Pub/Sub（SSUBSCRIBE）在故障转移中也不可靠
Redis 7.0+ 的 SSUBSCRIBE 确实能绑定 slot，但它只解决“跨节点广播”问题，不解决“连接生命周期管理”问题。主节点宕机后，SSUBSCRIBE 连接一样断开，且：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 新主节点不会继承旧连接，也不会恢复订阅上下文
- 没有内置重试或断线续订机制，全靠客户端自己重建
- 如果频道名没带
{}标签（如chat:room1→{chat}:room1），CLUSTER KEYSLOT计算结果可能漂移，导致发布/订阅落到不同节点
真正可用的补偿方案只有两种
别指望 Redis 自身修复，必须由应用层兜底：
- 用
XADD/XREADGROUP替代 Pub/Sub：消息写入即落盘，支持按 ID 回溯、ACK 确认、消费者组分发；故障期间未拉取的消息仍保留在 stream 中 - 若必须保留 Pub/Sub 接口，加一层“外部缓冲”：比如每次
PUBLISH同时写一条SETNX msg:<id> 1 EX 300</id>，再由独立 worker 定期扫描未消费 ID 并重推；但要注意并发和幂等 - 所有客户端必须实现完整的重连闭环：监听
__sentinel__:hello或轮询SENTINEL get-master-addr-by-name→ 关闭旧连接 → 新地址建连 → 重SUBSCRIBE→ 补漏逻辑（如查 last-seen-timestamp）
最常被忽略的一点：Pub/Sub 在集群里从来就不是为“不丢消息”设计的。它只保证“此刻在线的人看到最新广播”，而故障转移窗口期天然存在离线空档——想填这个空，得换模型，不是调参数。
