详解Redis哨兵模式下，主节点掉线而重新选取主节点的流程

⭐最核心的结论：所谓选举的过程不是直接选出新的主节点，而是先在哨兵节点中选出 leader ，再由 leader 负责后续主节点的指定。

---

假定当前环境：

• 三个哨兵(sentenal1, sentenal2, sentenal3)
• 一个主节点(redis-master)
• 两个从节点(redis-slave1, redis-slave2)

当主节点出现故障，就会触发以下一系列过程：

目录

一、判定主观下线

二、判定客观下线

三、选举出哨兵的 leader

1、每个哨兵节点都给其他所有哨兵节点发起⼀个 “拉票请求”。

2、收到拉票请求的节点会回复⼀个 “投票响应”，响应的结果有两种可能，即投 or 不投。

3、一轮投票完成之后，得票超过半数的哨兵节点将动成为 leader。

***选举leader的流程演示：

4、leader 节点负责挑选一个 slave 成为新的 master。

四、由leader挑选一个从节点作为新的主节点

挑选的规则

*哨兵节点的作用演示 

---

一、判定主观下线

哨兵节点通过心跳包判定 redis-master 服务器是否正常工作。如果心跳包没有如约而至，那么这个哨兵节点就会认为 redis-master 服务器挂了，这就是主观下线（SDown）。

注意，此时在在某一个哨兵节点的角度，还不能排除网络波动的对心跳包丢失的影响，所以只能是该哨兵节点单方面认为这个 redis-master 节点挂了，是“主观”的。

---

二、判定客观下线

此时，哨兵 sentenal1，sentenal2，sentenal3 均会对主节点故障这件事情进行投票。当故障得票数 >= 配置的法定票数之后，哨兵们就认为这个主节点确实挂了，即触发客观下线（ODown）。

法定票数可以在哨兵节点的配置文件中查看：

sentinel1.conf是哨兵节点sentinel1的配置文件

有些同学可能会有疑问，是否存在一种情况：出现非常严重的网络波动，导致所有的哨兵都联系不上 redis 主节点从而“误判”成主节点挂了呢？

当然是有的！然而，如果出现这个情况，怕是连用户的客户端也连不上 redis 主节点了，此时这个redis主节点基本也是无法正常工作的。

注意，“挂了”不一定指的就是进程崩了。只要无法正常访问主节点，都可以视为是主节点挂了。

---

三、选举出哨兵的 leader

接下来需要哨兵把剩余的 slave 中挑选出⼀个新的 master。

这个工作不需要所有的哨兵都参与，只需要选出个代表（称为 leader），由 leader 负责进行 slave 升级到 master 的提拔过程。这个选举的过程涉及到 Raft 算法。

假定⼀共三个哨兵节点 S1，S2，S3：