“Redis中的哨兵选举算法是如何实现的？”
一个工作7年的粉丝，去某外包公司面试，被问到这个问题不知道该怎么回答。
今天给大家分享一下这个问题的回答思路。
问题解析
Redis里面的Master-Slave集群，是不具备故障恢复能力的。
也就是Master节点挂了以后，需要从集群中的其他Slave节点选举新的Master继续提供服务。
因此在Redis里面引入了Sentinel哨兵机制，通过哨兵来监控集群的状态，实现Master选举。
哨兵是一个单独的进程，所以为了保证哨兵的可靠性，我们也会对哨兵做部署集群。
假设哨兵节点有3个，那这个时候这三个节点分别去监听Redis的三个主从节点，这里就存在一个问题：
一旦Redis主从集群的某个节点出现故障，而故障节点被其中一个Sentinel哨兵节点检测到，但是另外两个节点还没检测到，那三个哨兵节点如何在意见上达成意见上的一致呢？
同时，哨兵节点怎么判断哪一个Slave节点应该成为Master呢？
这就是这个问题的底层逻辑，也是候选人在面对这个问题的时候需要思考和回答的方向，下面来看一下高手的回答。
问题答案
当Redis集群中的Master节点出现故障，哨兵节点检测到以后，会从Redis集群中的其他Slave节点选举出一个作为新的Master。
具体的判断依据有两个部分：
第一部分： 筛选
第二部分： 综合评估
在筛选阶段，会过滤掉不健康的节点，比如（下线或者断线），或者没有回复Sentinel哨兵心跳响应的Slave节点。
同时，还会评估实例过往的网络连接情况，如果在一定时间内，Slave和Master经常性断链，而且超出了一定的阈值，也不会考虑。
经过筛选后，留下的都是健康的节点了。
接下来就对健康节点进行综合评估，具体有三个维度，按照顺序来判断。
- 根据Slave优先级来判断，通过 slave-priority 配置项（redis.conf），可以给不同的从库设置不同优先级，优先级高的优先成为master。
- 选择数据偏移量差距最小的，即slave_repl_offset与 master_repl_offset进度差距，其实就是比较 slave 与 原master 复制进度差距，避免丢失过多数据的问题。
- slave runID，在优先级和复制进度都相同的情况下，选用runID最好的，runID越小说明创建时间越早，优先选为master。
经过以上步骤，就可以选举出新的Master节点了。
另外，如果哨兵存在集群的情况下，如果其中一个哨兵节点认为Redis集群主线故障，另外两个哨兵还没感知到的情况下。
在进行Master选举之前，Sentinel哨兵集群需要通过共识算法来达成一致，这里用到了Raft协议。
总结
大家知道怎么回答了吗？
