Redis Sentinel哨兵模式的故障转移全过程

Redis哨兵（Sentinel）模式是Redis高可用性解决方案的核心。当主节点出现故障时，哨兵集群能够自动完成故障检测、领导选举和故障转移，确保系统持续提供服务。本文将深入剖析这一过程的每一个关键步骤。

第一阶段：故障发现与确认

哨兵的核心任务是监控。它每隔一定时间向主节点发送 PING 命令，用于检测节点状态。

1. 配置监控参数
   在 sentinel.conf 文件中，设置 down-after-milliseconds 参数。该参数定义了主节点在多长时间内无响应会被判定为“主观下线”。

2. 检测主观下线
   当哨兵发送 PING 命令后，如果在 down-after-milliseconds 毫秒内没有收到有效回复（PONG、LOADING、MASTERDOWN），该哨兵会将主节点标记为“主观下线”（SDOWN）。此时，这只是单个哨兵的私人判断。

3. 询问其他哨兵
   发现主节点主观下线的哨兵，会向其他所有监控该主节点的哨兵发送 SENTINEL is-master-down-by-addr 命令，询问它们是否也认为主节点下线。

4. 判定客观下线
   当足够数量的哨兵（数量由配置文件中的 quorum 参数决定）在规定时间内确认主节点确实“主观下线”，该主节点就会被正式标记为“客观下线”（ODOWN）。

第二阶段：哨兵领导者选举

一旦主节点被判定为客观下线，哨兵集群需要从众多哨兵中选出一个领导者，由它来具体执行后续的故障转移操作。这个过程采用了Raft算法的原理。

1. 发起投票
   确认主节点客观下线的哨兵，会将自己的运行ID通过 SENTINEL is-master-down-by-addr 命令广播给其他哨兵，要求它们选举自己作为领导者。

2. 处理投票请求
   收到投票请求的哨兵，在未响应过其他哨兵的请求的前提下，会同意第一个发起请求的哨兵成为领导者，并回复一个投票结果。

3. 统计票数
   发起选举的哨兵会收集其他哨兵的回复。一旦获得超过半数（配置中的 quorum 或多数派原则）的哨兵支持，它就会当选为哨兵领导者，并立即开始执行故障转移。

第三阶段：执行故障转移

当选出的哨兵领导者接管指挥权后，它将从现有的从节点中挑选一个升级为新的主节点。

1. 筛选从节点
   领导者会遍历所有健康的从节点，并根据以下优先级进行筛选：

   • 过滤掉断开连接时间过长的从节点。
   • 优先选择 replica-priority（优先级）配置较高的节点。
   • 如果优先级相同，选择复制偏移量最大（即数据最完整）的节点。
   • 如果偏移量也相同，选择运行ID较小的节点。

2. 执行升级命令
   选定目标从节点后，领导者会发送 SLAVEOF NO ONE 命令给该节点，使其断开与原主节点的复制关系，并转变为新的主节点。

3. 修正其他从节点
   领导者会发送 SLAVEOF 命令给剩余的所有从节点，让它们指向新的主节点地址，开始复制新的数据。

4. 通知客户端
   故障转移完成后，领导者会广播新的主节点地址信息。订阅了哨兵频道（+switch-master）的客户端会收到通知，从而更新连接配置，将写请求发送到新的主节点。

5. 处理旧主节点
   如果原主节点重新上线，哨兵领导者会发送 SLAVEOF 命令将其配置为新主节点的从节点，以保持数据一致性。

关键配置参数说明

为了更好地控制上述过程，需要在配置文件中关注以下参数。

注意：parallel-syncs 设置得越大，故障恢复速度越快，但也可能瞬间让新主节点承担巨大的网络流量压力，导致服务中断，通常建议设置为 1。

总结操作逻辑

故障转移的核心在于“共识”与“自动修正”。通过心跳检测发现异常，通过Raft算法达成共识选出执行者，最终通过 SLAVEOF 命令重置集群拓扑。整个过程对于业务方是透明的，只要客户端正确订阅了哨兵事件，即可实现无缝切换。