【Redis主从架构】redis哨兵核心原理的深入解析(包括slave选举算法)
10.【Redis主从架构】redis哨兵核心原理的深入解析(包括slave选举算法)
1. sdown和odown转换机制
1.1 sdown-主观宕机
sdown是主观宕机，就一个哨兵如果自己觉得一个master宕机了，那么就是主观宕机了。
- 主观宕机原理：
sdown 达成的条件很简单，如果一个哨兵ping一个master，超过 is-master-down-after-milliseconds指定毫秒数之后，如果还没有响应，就主观认为master宕机了。
1.2 odown-客官宕机
odown 是客观宕机，如果quorum数量的哨兵都觉得一个master宕机了，就认为master宕机了。
- 客观宕机原理：
如果一个哨兵在指定时间内，收到了quorum指定数量的其他哨兵也认为这个master是sdown了，那么就认为是odown了，客观认为是master宕机。
2. 哨兵集群的自动发现机制
哨兵互相之间的发现，是通过redis的pub/sub系统实现的，每个哨兵都会往
sentinel:hello这个channel里面发送一个消息，这时候其他哨兵都可以消费到这条消息，并感知到其他哨兵的存在。
每隔两秒钟，每个哨兵都会往自己健康的某个master+slaves对应的_sentinel_（可以理解为Topic，MQ广播机制）：hello channel里发送一个消息，内容是自己的host，ip和runid还有对这个master的配置
每个哨兵都会去监听自己监控的每个master+slaves对应的_sentinel_:hello channel,然后去感知同样在监听这个master+slaves的其他哨兵的存在。
每个哨兵还会跟其他哨兵交换对master的监控配置，互相进行监控配置的同步。
3. slave配置的自动纠正
哨兵会负责自动纠正salve的一些配置，如果 slave 如果要成为 master，哨兵会确保slave在复制新的master的数据。
如果一个slave连接到一个错误的master上，比如故障转移之后，那么哨兵会确保他们连接到正确的master上。
4. slave->master选举算法
如果一个master被认为odown了，而且majority哨兵会允许主备切换，那么某个哨兵会执行主备切换操作，此时需要先选举一个slave出来。选举的过程中会考虑slave的一些信息
- 跟master断开连接的时长
- slave优先级
- 复制offset
- run id
- 哨兵什么时候认为salve不适合选举成为master？
一个slave跟master断开连接的时间已经超过了down-after-milliseconds的10倍，外加master宕机的时长，那么salve被认为不适合被选举为master。
(down-after-milliseconds * 10) + millisecond_since_master_is_in_SDOWN_state
- slave选举为master需考虑的因素，即salve如何排序？
- 按照slave优先级进项排序，slave priority越低，优先级越高
- 如果slave priority相同，那么看replicate offset，哪个slave复制了更多的数据，offset越靠后，优先级就越高。
- 如果上面两个条件都相同，那么就选择一个run id比较小的按个slave。
5. quorum 和 majority 参数详解
quorum： 影响redis客观宕机，必须要有quorum数量的哨兵认为master宕机了，才认为是odown，然后选举一个哨兵来做主备切换。
majority：影响 选举 做主备切换的哨兵，选举出来做哨兵切换的哨兵，必须得到majority个哨兵的授权，才能正式执行主备切换。
如果quorum < majority, 比如majority就是3，quorum设置为2，那么3个哨兵授权就可以进行主备切换。
如果quorum >= majority, 那么必须quorum数量的哨兵都授权，比如5个哨兵，quorum是5，那么必须5个哨兵都同一授权，才能进行主备切换。
6. configuration epoch
哨兵会对一套 redis master+slave进行监控，会有相应的监控的配置
执行切换的按个哨兵，会从要切换到新master (slave->master) 那里得到一个configuration epoch，这就是version号，每次切换的version都是唯一的，如果第一个选举出的哨兵切换失败了，那么其他哨兵，会等待failover-timeout时间，然后接替继续执行切换，此时会重新获取一个新的configuration epoch，作为新的version号。
总结：
执行切换的哨兵会从 新的master那里得到一个version号，假如主备切换失败，意味着：要选举新的slave，要获取新的版本号。注意：版本号唯一。
7. configuration传播
哨兵完成切换之后，会在自己本地更新生成最新的master配置，然后同步给其他的哨兵，就是通过之前所说的pub/sub消息机制实现。
之前讲解的version号也很重要，因为各种消息都是通过一个channel去发布和监听的，所以一个哨兵完成一次新的切换，新的master和跟着新的version号的其他哨兵都是根据版本号的大小来更新自己的master配置的。
总结：
哨兵执行主备切换之后，新的master 的ip，端口号，runid都发生了变化。 哨兵会发送一条消息到 pub/sub 消息系统，通知其他哨兵 更新最新的master配置。
总结：
