Redis中一次故障转移流程

一般情况下Redis Sentinel集群至少需要3个节点，类似zk的集群，一次选举至少需要n/2+1个节点认同才行（当然并不是说少于3个不能工作，一台就可以用的( ⊙ o ⊙ )啊！）。
进程启动是有先后顺序的，现在假设已经有2台sentinel存在了，现在启动第三台。看下整个流程

1， sentinel（简称S）上线后，向配置的master发送info命令，解析出master及其slave的信息（每10秒）

此处S已经获得了master及其slave的信息

image.png

2，sentinel发布/订阅master特定的channel，获取其他sentinel信息 （每2秒）

此处S获得了其他sentinel的信息，那么S已经获得了所有该架构中的所有redis进程信息

image.png

3，sentinel向所有已知的master/slave/sentinel发送ping命令，确定节点是否正常（每秒）

image.png

4，如果某个节点在指定时间没未返回ping成功信息，则认为其主观下线。

主观下线：指的是单个 Sentinel 实例对服务器做出的下线判断

4.1，多个 Sentinel 实例在对同一个服务器做出“主观下线” 判断， 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服务器客观下线判断

客观下线：只适用于主服务器
slave和sentinel的主观下线不影响集群使用

5，如果主观下线的是master，则开始选举sentinel的leader。

sentinel的leader主要是要执行故障转移命令，所以选举方式比较粗暴。
也有同学提出过，为什么不事先选举好，个人觉得也可以，只是方案不同罢了

6，发现主观下线的sentinel向所有其他sentinel发送成为leader的命令，如果其他sentinel还未投过票，则同意，否则拒绝。

7，sentinel发现自己的票数过半且到达quorum（启动时配置）的值，则成为leader，否则隔断时间进行新一轮选举

这里解释了为什么最少要3台，和zk一样如果是偶数台，那么超过一半的值和奇数台是一样的。(4/2 = 2 3/2 = 2)，quorum由配置项配置

8，leader选出后开始操作故障转移，选取一个slave

8.1，选择slave-priority优先级最高的

slave-priority通过配置项配置

8.2，选择offset最大的，offset最大说明对master的数据复制的最完整，如果存在则返回，不存在则继续

8.3，选择run_id最小的slave节点，run_id最小说明slave节点启动最早

9，向选举出来的slave发送 salveof no one命令，变成leader

10，向其他salve发送命令，使其转为新leader的slave，然后从新master同步数据

11，leader会把之前的master设为slave，并且每秒ping，当其恢复后，sentinel会使其去复制新master节点的数据