哨兵故障转移机制

什么是哨兵故障转移

Redis 哨兵（Sentinel）的故障转移（Failover）是指在主节点发生故障时，哨兵系统自动将一个从节点提升为新的主节点，并重新配置整个集群的过程。这是 Redis 高可用的核心保障机制。

故障转移的完整流程

第一阶段：检测主节点故障

当哨兵确认主节点进入”客观下线”（ODOWN）状态后，即开始触发故障转移。一个哨兵会向其他哨兵发起提议，请求执行故障转移。

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

在故障转移开始前，哨兵系统会选举一个”领导者哨兵”来负责执行故障转移操作。这个选举过程使用 Raft 算法中的投票机制——哪个哨兵最先获得半数以上（超过 quorum）的投票，就成为领导者。

第三阶段：选举新主节点

领导者哨兵会从当前的从节点列表中选出一个作为新主节点。选举遵循严格的优先级规则：

1. 剔除不健康的从节点：排除所有处于主观下线（SDOWN）、断线或最近没有与主节点通信的从节点
2. 按优先级排序：选择 slave-priority（或 replica-priority）值最小的从节点（值越小优先级越高）
3. 按复制偏移量排序：如果优先级相同，选择复制偏移量最大的从节点（数据最完整）
4. 按运行 ID 排序：如果前两者都相同，选择运行 ID 最小的从节点

第四阶段：执行角色切换

1. 领导者哨兵向选中的从节点发送 SLAVEOF NO ONE 命令，将其提升为主节点
2. 等待新主节点完成角色切换（通常需要数毫秒）
3. 更新哨兵内部的主节点信息，将原主节点标记为故障

第五阶段：重新配置其他从节点

1. 领导者哨兵向其他所有从节点发送 SLAVEOF 命令，让它们复制新的主节点
2. 从节点开始从新主节点同步数据

第六阶段：通知客户端

哨兵通过发布/订阅（Pub/Sub）通道 +switch-master 发布主节点变更消息，订阅了该通道的客户端可以收到通知并更新连接信息。

第七阶段：处理旧主节点恢复

如果原主节点后来恢复上线，哨兵会将其降级为从节点，并让它复制新的主节点，防止”脑裂”情况发生。

关键配置参数

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1

• quorum=2：至少 2 个哨兵同意主节点故障才触发故障转移
• down-after-milliseconds=30000：30 秒无响应视为下线
• failover-timeout=180000：故障转移超时时间
• parallel-syncs=1：每次只让一个从节点同步新主节点，减少负载

故障转移过程中的服务可用性

在故障转移期间（通常 10-30 秒），Redis 服务对于写操作是不可用的，因为此时没有主节点可写入。读操作如果配置了从节点可读，则可以继续从从节点读取（但可能有数据不一致）。故障转移完成后，服务自动恢复。

总结

哨兵的故障转移机制是一个自动化的、由哨兵集群协作完成的主从切换流程。它保证了在主节点宕机时，系统能自动恢复写入能力，实现高可用。理解这个机制对于生产环境部署 Redis 至关重要。