大厂面试题-Redis中的哨兵选举算法是如何实现的？

目录

问题解析

问题解答

---

问题解析

Redis里面的Master-Slave集群，是不具备故障恢复能力的。

也就是Master节点挂了以后，需要从集群中的其他Slave节点选举新的Master继续提供服务。

(如图)因此在Redis里面引入了Sentinel哨兵机制，通过哨兵来监控集群的状态，实现Master选举。

哨兵是一个单独的进程，所以为了保证哨兵的可靠性，我们也会对哨兵做部署集群。

假设哨兵节点有3个(如图)，那这个时候这三个节点分别去监听Redis的三个主从节点，这里就存在一个问题：

一旦Redis主从集群的某个节点出现故障，而故障节点被其中一个Sentinel哨兵节点检测到，但是另外两个节点还没检测到，那三个哨兵节点如何在意见上达成意见上的一致呢？

同时，哨兵节点怎么判断哪一个Slave节点应该成为Master呢？

这就是这个问题的底层逻辑，也是候选人在面对这个问题的时候需要思考和回答的方向，下面来看一下高手的回答。

问题解答

当Redis集群中的Master节点出现故障，哨兵节点检测到以后，会从Redis集群中的其他Slave节点选举出一个作为新的Master。

具体的判断依据有两个部分：

第一部分：筛选

第二部分：综合评估

在筛选阶段，会过滤掉不健康的节点，比如(下线或者断线)，或者没有回复Sentinel哨兵心跳响应的Slave节点。

同时，还会评估实例过往的网络连接情况，如果在一定时间内，Slave和Master经常性断链，而且超出了一定的阈值，也不会考虑。

经过筛选后，留下的都是健康的节点了。

接下来就对健康节点进行综合评估，具体有三个维度，按照顺序来判断：

1.   根据Slave优先级来判断，通过slave-priority配置项(redis.conf)，可以给不同的从库设置不同优先级，优先级高的优先成为master。

2.   选择数据偏移量差距最小的，即slave_repl_offset与master_repl_offset进度差距，其实就是比较slave与原master复制进度差距，避免丢失过多数据的问题。

3.   slave runID，在优先级和复制进度都相同的情况下，选用runID最好的，runID越小说明创建时间越早，优先选为master。

经过以上步骤，就可以选举出新的Master节点了。

另外，如果哨兵存在集群的情况下，如果其中一个哨兵节点认为Redis集群主线故障，另外两个哨兵还没感知到的情况下。

在进行Master选举之前，Sentinel哨兵集群需要通过共识算法来达成一致，这里用到了Raft协议。