前言
前面Redis Sentinel 架构原理详解(二)介绍了redis集群中sentinel的三种定时监控任务，还了解了主观下线，客观下线的概念，以及sentinel is-master-down-by-addr命令的作用。这里再和大家一起学习下Redis Sentinel架构故障转移前的Sentinel leader 选举，以及redis新的master如何选择。
故障转移前的 leader 选举
当 sentinel 集群确认 master odown，需要选举出一个 leader 节点来进行故障转移，选举过程如下：
-
每个在线的 sentinel 节点都有资格成为 leader，当它确认主节点客观下线时候，会向其他 sentinel 节点发送
sentinel is-master-down-by-addr命令，要求将自己设置为leader，比如 sentinel-0 节点首先发起请求成为 leader 的请求。 -
每个 sentinel 节点都只能投出一票，于是当 sentinel-0 节点发起成为 leader 的请求后，会得到 sentinel-1 和 sentinel-2 节点的投票，总共得到 2 票，得到的票数和以下公式计算的值作比较：
max(quorum, num(sentinels) / 2 + 1)
= max(2, 3 / 2 + 1)
= max(2, 1 + 1)
= max(2, 2)
= 2
当得到的票数 >= max(quorum, num(sentinels) / 2 + 1) 的值，那么该 sentinel节点成为 leader，于是，sentinel-0 节点成为 leader。
3.比如下一个确认 master 客观下线的 sentinel 节点为 sentinel-1，当它发起成为 leader 的请求后，由于 sentinel-2 节点已经给 sentinel-0 节点投过票了，于是它只能得到 sentinel-0 节点投的一票，所以它不能成为 leader，而当 sentinel-2 发起请求成为 leader 的请求后，它一票都得不到。于是当已经选举出 leader 后，就不会再继续进行选举流程了，因为是没有意义的。
4.如果一次选举没有选举出 leader，那么会进行下一次选举。
5.总结：正常情况下，哪个 sentinel 节点最先确认 master 客观下线，哪个 sentinel 节点就会成为执行故障转移的 leader。
故障转移前新的master选择
要执行故障转移，首先要从 slave 中选择一个作为新的 master，选择的准则如下：
不选择不健康的 slave，以下状态的slave是不健康的：
- 主观下线的 slave
- 大于等于5秒没有回复过 sentinel 节点 ping 响应的 slave
- 与 master 失联超过
down-after-milliseconds * 10秒的 slave
对健康的 slave 进行排序
- 选择 priority（从节点优先级，可配置，默认100）最低的从节点，如果有优先级相同的节点，进行下一步。注意如果这个值配置为0，则代表禁止该节点成为 master。
- 选择复制偏移量最大的从节点（复制的最完整），如果有复制偏移量相等的节点，进行下一步。
- 选择 runid 最小的从节点。
然后就是 leader 进行故障转移的过程了：
- leader 对选择出来的要成为 new master 的 slave 执行
slaveof no one命令让其成为 new master。 - leader 会向剩余的 slave 发送命令，让它们成为 new master 的 slave。
- leader 会将 old master更新为slave点，并保持着对其关注，当其恢复后命令它去复制 new master。复制规则和
parallel-syncs配置有关。该配置指定了在执行故障转移时，最多可以有多少个 slave 同时对 new master 进行同步，这个数字越小，完成故障转移所需的时间就越长。如果从服务器被设置为允许使用过期数据集(redis.conf 中slave-serve-stale-data配置) ，那么你可能不希望所有 slave 都在同一时间向 new master 发送同步请求，因为尽管复制过程的绝大部分步骤都不会阻塞slave， 但 slave 在 load new master 发来的 RDB 文件时， 仍然会造成其在一段时间内不能处理请求。如果全部 slave 一起对 new master 进行同步， 那么就可能会造成所有 slave 在短时间内全部不可用的情况出现。你可以通过将这个值设为 1 来保证故障转移后最多只有一个 slave 处于不可用状态。但这样的话，全部 slave 的数据同步就是串行的，这样就会增加故障转移整个过程的时间。
总结
这里介绍了redis哨兵集群中的sentinel的leader如何选举，以及redis主从中的新master如何选择，后续再一起学习下Sentinel 集群的quorum 和majority，configuration epoch，以及Redis Sentinel可能出现的问题以及解决办法。
来源：CSDN
作者：爱琴孩
链接：https://blog.csdn.net/qq_28165595/article/details/104102693