【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的一些信息

1. 跟master断开连接的时长
2. slave优先级
3. 复制offset
4. 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如何排序？

1. 按照slave优先级进项排序，slave priority越低，优先级越高
2. 如果slave priority相同，那么看replicate offset，哪个slave复制了更多的数据，offset越靠后，优先级就越高。
3. 如果上面两个条件都相同，那么就选择一个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配置。

总结：

本文使用 mdnice 排版