【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配置。

总结:

image-20200519213939805
image-20200519213939805

本文使用 mdnice 排版

以上是 【Redis主从架构】redis哨兵核心原理的深入解析(包括slave选举算法) 的全部内容, 来源链接: utcz.com/a/29984.html

回到顶部