Redis 哨兵模式切换主节点后，发布订阅（Pub/Sub）消息无法恢复，因为该模式不持久化且不复制；恢复的核心是客户端主动重连新主节点并重新订阅频道。

快速处理思路

若当前业务已发生中断，优先检查客户端是否具备自动重连能力，而非尝试从 Redis 服务端找回消息。

适用场景：生产环境哨兵切换后消费者停止收消息。

操作动作：

1. 确认客户端使用的是支持哨兵的连接池（如 JedisSentinelPool），而非硬编码主节点 IP。
2. 检查客户端日志是否有 connection reset 或 timeout 报错，确认是否触发重连逻辑。
3. 若客户端无自动重连，需重启消费者服务以建立对新主节点的连接。

风险边界：重启服务期间发布的消息仍会丢失，无法补救。

为什么会这样

Redis 发布订阅是纯内存、无状态的通信模式，消息不经过复制流也不写入持久化文件。

当主节点宕机触发哨兵切换时，原主节点上的 TCP 连接立即失效，未消费的消息随进程退出而清除。新选举的主节点是从节点提升而来，它只同步数据键值，不同步 Pub/Sub 的订阅状态和内存消息。因此，哨兵只能保证服务地址可用，无法保证消息不丢失。

分步处理

要从架构上减少中断影响，需在客户端和哨兵配置两端同时优化。

1. 哨兵侧配置检查

确保哨兵能及时发现故障并切换，缩短中断窗口。

sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 180000

验证结果：主节点宕机后，哨兵日志应在 down-after-milliseconds 设定时间内输出 +switch-master。

2. 客户端重连逻辑实现

客户端需监听哨兵事件或捕获连接异常，执行重订阅。

on connection_lost:
  new_addr = sentinel.get_master_addr_by_name("mymaster")
  conn = redis.connect(new_addr)
  conn.subscribe("channel_a", "channel_b")

风险边界：重连期间发布的消息无法追回，业务需容忍少量重复或丢失。

3. 认证配置同步

若主节点开启 requirepass，哨兵配置必须包含 auth-pass，否则切换后客户端认证失败。

sentinel auth-pass mymaster your_password

怎么验证是否生效

切换完成后，通过以下命令确认客户端已恢复订阅。

1. 检查订阅数量

在 Redis 新主节点执行：

redis-cli PUBSUB NUMSUB channel_a

状态判断：返回的订阅客户端数量应大于 0，且与实际消费者数量一致。

2. 检查客户端日志

确认客户端无持续报错，且有重新订阅成功的日志记录。

3. 消息流量监控

观察业务侧消息接收速率，确认在切换完成后流量恢复正常，无长期归零现象。

常见坑

• 误以为 AOF 能保存消息：开启 appendonly yes 仅持久化键值数据，不记录 Pub/Sub 操作，重启后消息依然丢失。
• 硬编码主节点地址：客户端直接连接原主节点 IP，切换后无法自动发现新主节点，导致永久断连。
• 忽略从节点只读限制：若未配置 replica-read-only yes，故障恢复期间可能有人为写入导致主从数据不一致。
• 静默失联：TCP 连接可能未触发 FIN 信号，应用层无报错但收不到消息，需增加心跳检测机制。

常见问题

哨兵切换后能找回丢失的 Pub/Sub 消息吗？

不能。Redis Pub/Sub 消息不持久化，主节点宕机后未消费消息立即清除，服务端无备份。

为什么客户端连上新主节点后还是收不到消息？

因为订阅状态不复制。客户端必须重新执行 SUBSCRIBE 命令，仅建立 TCP 连接不够。

哨兵模式适合做可靠消息队列吗？

不适合。若要求消息不丢失，应使用 Kafka、RabbitMQ 或 Redis Stream 而非 Pub/Sub。

参考来源

• 如何解决 Redis 发布订阅模式下 Master 宕机导致的消息中断_配置 Sentinel 自动切换
• Redis 发布订阅系统崩溃后如何快速恢复_配置 Redis 高可用策略防止单点故障
• Redis 哨兵模式下如何恢复异常节点_修复从库并重启
• Redis 哨兵集群故障恢复原理