Redis哨兵到底是怎么监控和切换主节点的，原理其实没那么复杂但挺关键

Redis哨兵系统说白了就是给Redis主从架构请来的一个“保安队”，这个保安队不负责具体的数据存储和读写，它的核心任务就一个：确保“老板”（主节点）活着，老板”出事了，能马上从“员工”（从节点）里选出一个新的“老板”，并通知所有“人”（客户端）以后要听新“老板”的，保证公司（Redis服务）能不间断运行。

这个“保安队”的工作可以拆解成三个核心步骤：监控、判定故障、切换主节点。

第一步：监控——不停地问“老板，你还好吗？”

哨兵不是一个单独的个体,它自己也是一个高可用的集群，通常由三个或更多个哨兵实例组成，这样做是为了防止单个哨兵自己出问题而误判主节点挂了。

每个哨兵实例都会以每秒一次的频率,向它监控的所有主节点、从节点以及其他哨兵实例发送一条PING命令，这就像保安队里的每个保安，每隔一秒就用电台呼叫一下老板和各个关键岗位：“一切正常吗？”

正常情况下,被PING的节点会回复一个PONG，只要收到PONG，哨兵就知道这个节点目前是健康的，这个监控过程是持续不断的，确保了哨兵能实时掌握整个集群的健康状况。

第二步：判定故障——什么时候认定“老板”真的挂了？

如果某个哨兵在配置的时间（比如30秒）内没有收到主节点的PONG回复，它首先不会马上行动，而是会有点“疑神疑鬼”，它会想：“是不是我自己的网络出了问题？还是老板真的不行了？”

这个哨兵并不会立刻宣布主节点下线,它只是主观地认为主节点可能下线了，这个状态叫做“主观下线”。

这个发现异常的哨兵会去问保安队里的其他同事：“嘿，你们还能联系上老板吗？”它会向其他哨兵实例发送命令，询问它们如何看待这个主节点的状态。

其他哨兵也会根据自己的监控情况回复它,如果足够数量（这个数量是可以配置的，通常需要超过哨兵总数的一半）的哨兵都报告说自己也联系不上主节点了，哨兵团队就会达成一个客观的共识：主节点确实挂了，这个状态就叫“客观下线”。

一旦达成“客观下线”的共识，保安队就知道，不能再等了，必须启动紧急预案——选举新的老板。

第三步：切换主节点——民主选举新“老板”并通知全员

保安队内部要先选出一个“队长”来负责主持这次切换工作，这个选举过程遵循的是民主集中制，任何一个发现主节点客观下线的哨兵，都可以发起投票，要求大家选它当队长，但每个哨兵在每轮选举中只能投一次票（包括投给自己），最先发现故障的哨兵更容易获得多数票而当选为“队长”哨兵。

“队长”哨兵产生后，它就肩负起挑选新主节点的重任，它不会随便选一个从节点上来，它会根据一套规则来挑选最合适的“接班人”：

1. 健康优先：首先排除掉那些网络连接不稳定或者响应太慢的从节点。
2. 数据同步程度：它会优先选择数据和新旧主节点最接近的从节点，也就是数据复制偏移量最大的那个，这样可以最大程度保证数据不丢失。
3. 优先级：如果同步程度差不多，它会看Redis配置文件里给从节点设置的slave-priority优先级，数字越小优先级越高。
4. 运行ID：如果连优先级都一样，那就选运行ID最小的那个（可以理解为工号最老的员工）。

选定了新主节点后,“队长”哨兵就会开始执行切换流程：

1. 它会给这个被选中的从节点发送SLAVEOF NO ONE命令，让它“翻身做主人”，停止复制旧主节点，并开始将自己提升为主节点。
2. 它会向其他所有从节点发送新的SLAVEOF命令，让它们转而复制这个新的主节点。
3. 也是至关重要的一步,哨兵会将自己监控的主节点信息更新为这个新的主节点。

哨兵会持续把这个最新的“老板”是谁的信息对外发布，客户端程序通常会连接到哨兵系统来查询当前有效的主节点地址，当切换完成后，客户端下次来问的时候，哨兵就会告诉它新主节点的地址，客户端就会自动连接到新主节点上继续工作，整个过程对应用程序来说是近乎无感的。

这就是Redis哨兵监控和切换主节点的核心原理,它通过多实例的集体决策来避免误判，通过一套选举和筛选规则来确保选出最合适的新主节点，最终实现了Redis的高可用性。

（参考资料：主要基于Redis官方文档中关于Sentinel的说明，以及《Redis设计与实现》一书中对Sentinel机制的阐述。）