哨兵机制
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 协议。
