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