Sdown和Odown转换机制
Sdown（主观宕机）
如果一个哨兵认为master宕机了，那么就是主观宕机。
具体表现在， 如果哨兵在ping 集群中的master节点，在等待超时is-master-down-after-milliseconds的毫秒时间后并未收到心跳回复后，就会认为master节点宕机。
Odown（客观宕机）
当超过了quorum(翻译：法定人数)的哨兵都主观认为master节点宕机了，此时，哨兵就切换为客观认为master节点宕机。
Sdown到Odown的转换条件
当一个哨兵在指定时间内，收到了quorum指定数量的其他哨兵也认为这个master节点sdown后，那么就可以认为是odown了。
哨兵集群发现机制
哨兵之间的发现，是通过redis的pub/sub订阅通知的系统实现的。
（1）每个哨兵会监控指定的master+slave集群对应的channel（__sentinel__:hello）然后，每隔两秒钟会往这个channel里发送一条消息，这时候所有监控这个channel的哨兵节点都可以消费到这个消息。
（2）每个哨兵能够感知到同样在监控这个channel的其他哨兵的存在。
（3）每个哨兵会跟其他哨兵交换对master的监控配置，互相同步监控配置信息。
发送消息的主要内容： 哨兵自身的host、ip、runid，以及对master监控的配置信息。
Slave配置的自动纠正机制
哨兵节点能够负责自动纠正slave节点的一些配置。
比如，slave节点如果要成为潜在的master候选节点，哨兵会确保slave节点是在复制现有的master节点的数据。如果slave节点连接到一个错误的master节点上，那么在故障转移之后，哨兵会确保其他slave节点能够连接到正确的master节点上面。
Slave到Master的选举算法
如果超过了quorum数量的哨兵都认为master节点sdown了，就会被认定为master节点odown；同时，有majority数量的哨兵都允许了主备切换，那么就会有一个哨兵去执行主备切换（故障转移）的操作，然后通过选举算法，选举一个slave节点成为新的master节点。
选举算法考虑的信息
（1）slave节点跟旧master节点的断开连接时长，断开连接时长越短，越有机会成为master节点。
如果一个slave跟master断开连接已经超过了
down-after-millsenconds的10倍，外加上master的宕机时长，那么就可以认为这个slave节点不适合选举为新的master节点。
（2）slave节点的优先级，优先级越高，越有机会成为master节点。
如果slave节点的slave priority越低，则对应的优先级就越高。
（3）同步数据的offset。同步的数据越多，offset越靠后，越有机会成为master节点。
如果slave priority相同，那么就会看 replica offset（offset越靠后，说明slave复制的数据越多），对应的优先级也就越高。
（4）slave节点的run id。
如果存在多个slave节点的slave priority和replica offset都相同，那么就会选择run id比较小的slave节点。
quorum和majority
每次一个哨兵要进行主备切换，首先需要有quorum数量的哨兵都认为master节点odown了，然后选举一个哨兵来做主备切换。同时，这个哨兵，还需要得到majority数量的哨兵的授权才能正式执行主备切换。
如果 quorum < majority ，那么必须要有majority数量的哨兵授权，才可以执行切换。
如果quorum >= majority，那么必须要有quorum数量的哨兵授权，才能执行切换。
configuration epoch
每一次执行切换的哨兵，会从要切换为新master节点那里，得到一个configuration epoch(其实就是一个version号）。每次切换的version号都是唯一的。
如果第一个选举出来的哨兵切换失败，那么其他哨兵，会等待failover-timeout时间，然后接替继续执行切换，此时就会重新从要切换为master的节点那里获取一个新的configuration epoch，作为新的version号。
configuration传播
哨兵完成切换后，会在本地更新生成最新的master配置，然后通过pub/sub消息机制将配置同步给其他的哨兵。
其他的哨兵会根据version号的大小来更新自己的master配置信息。
哨兵的每一次切换，都会生成一个新的version号，新的master配置是跟着新的version号的。
原理流程图
若有收获，就点个赞吧
0 人点赞
