在 Redis Sentinel（哨兵）集群中，节点的发现、连接以及故障通知机制

1. 新哨兵进入集群：发现与建立连接

新哨兵（Sentinel N）加入集群时，并不需要预先知道其他哨兵的 IP 地址，它只通过配置文件获知 主库（Master） 的地址。

发现流程

1. 连接主库：Sentinel N 启动后，首先与配置文件中的主库建立两条连接：
   • 命令连接（Command Connection）：用于发送 INFO 等命令。
   • 订阅连接（Pub/Sub Connection）：订阅主库上的专用频道 __sentinel__:hello。
2. 自我介绍（发布）：Sentinel N 每隔 2 秒向主库的 __sentinel__:hello 频道发送一条消息，包含自己的 IP、端口、ID 以及它对主库状态的感知。
3. 发现同行（订阅）：因为所有哨兵都订阅了这个频道，Sentinel N 会收到其他哨兵发出的消息，从而获取其他哨兵的联系方式。
4. 建立相互连接：Sentinel N 发现其他哨兵后，会与它们建立命令连接。哨兵之间不会建立订阅连接，订阅仅存在于哨兵与主/从库之间。

与从库建立连接

• 哨兵通过向主库发送 INFO replication 命令获取所有从库（Slave）的列表。
• 随后，哨兵会与每个从库建立命令连接（用于心跳检测）和订阅连接（用于发现其他潜在哨兵）。

2. 哨兵下线：感知与清理

哨兵的下线通常是通过心跳超时被其他节点感知的。

• PING 机制：哨兵之间、哨兵与主从库之间会定期（默认 1s）发送 PING 命令。
• 主观下线（SDOWN）：如果某个哨兵（Sentinel A）在 down-after-milliseconds 时间内没有收到 Sentinel B 的有效回复，Sentinel A 会在内部将其标记为下线。
• 清理逻辑：
  • 其他哨兵视角：如果一个哨兵长期下线，其他哨兵会在一段时间后从其维护的实例字典中将其移除。
  • 客户端视角：客户端（Jedis/Lettuce 等）通常连接的是哨兵集群的一个子集。如果连接的哨兵宕机，客户端会捕获异常并尝试连接配置文件中提供的下一个哨兵地址。

3. 故障重连：如何通知客户端

这是保证高可用的核心。当主库故障，哨兵集群完成领头选举和故障转移（Failover）后，需要将新主库地址通知给客户端。

通知机制：基于 Pub/Sub 的主动推送

客户端在初始化时，不仅会通过哨兵获取主库地址，还会向哨兵订阅特定的频道（Channels）。

1. 订阅事件：客户端会监听哨兵上的 +switch-master 频道（主库切换）和 +reboot 等频道。
2. 哨兵发布：当故障转移结束，哨兵确认了新的 Master 后，会在其内部发布一条消息： +switch-master <master-name> <old-ip> <old-port> <new-ip> <new-port>
3. 客户端更新：
   • 客户端收到该订阅消息后，会触发回调函数。
   • 客户端内部会关闭旧的连接池，根据消息中的 new-ip 和 new-port 重建连接池，指向新的主库。
4. 兜底机制（从库重连）：如果由于网络抖动客户端错过了订阅消息，当它尝试向旧主库写入数据时，会收到报错或超时。此时客户端通常会重新向哨兵发起 get-master-addr-by-name 请求来获取最新地址。

总结表