1 sdown和odown转换机制

两种失败状态

1.1 概念

• sdown主观宕机
  一个哨兵自己觉得一个master宕机
• odown客观宕机
  quorum数量的哨兵都觉得一个master宕机

1.2 达成条件

• sdown
  一个哨兵ping一个master，超过is-master-down-after-milliseconds
• odown
  一个哨兵在指定时间内，收到了quorum指定数量的其他哨兵也认为那个master是sdown了，那么就认为是odown

2 自动发现机制

通过Redis的pub/sub实现哨兵互相之间的发现，每个哨兵都会往__sentinel__:hello这个channel发一个消息，此时所有其他哨兵都可消费到该消息，于是感知到其他哨兵的存在.

每隔2s，哨兵都会往自己监控的某个master+slaves对应的__sentinel__:hellochannel里发一个消息，内容为自己的host、ip和runid还有对该master的监控配置

每个哨兵也会去监听自己监控的每个master+slaves对应的__sentinel__:hello channel，然后去感知到同样在监听这个master+slaves的其他哨兵的存在

每个哨兵还会跟其他哨兵交换对master的监控配置，互相进行监控配置的同步

3 slave配置的自动纠正

哨兵会负责自动纠正slave的一些配置,比如

• slave要成为潜在的master候选人，哨兵会确保slave复制现有master的数据
• slave连接到了一个错误的master上，比如故障转移之后，那么哨兵会确保它们连接至正确的master

4 slave => master选举算法

若一个master被认为odown了，而且majority数量的哨兵都允许了主备切换，那么某个哨兵就会执行主备切换操作，此时首先要选举一个slave,会考虑slave的一些信息

• 跟master断开连接的时长
• slave优先级
• 复制offset
• run id

若一个slave跟master断开连接的时间已经超过down-after-milliseconds的10倍，外加master的宕机时长，那么slave就会被认为不适合选举为master

(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

  

 

  
1
 

接下来会对slave进行排序

1. 按照slave优先级进行排序，slave priority越低，优先级就越高
2. 如果slave priority相同，那么看replica offset，哪个slave复制了越多的数据，offset越靠后，优先级就越高
3. 如果上面两个条件都相同，那么选择一个run id比较小的那个slave

5 quorum和majority

每次一个哨兵要做主备切换，首先需要quorum数量的哨兵认为odown，然后选举出一个哨兵来做切换
该哨兵还得得到majority个哨兵的授权，才能正式执行切换

• 若quorum < majority
  比如5个哨兵，majority就是3，quorum设置为2，那么就3个哨兵授权就可以执行切换

• 若quorum >= majority
  那么必须quorum数量的哨兵都授权，比如5个哨兵，quorum是5，那么必须5个哨兵都同意授权，才能执行切换

6 configuration epoch

哨兵会监控一套Redis master+slave，并有相应的监控配置

执行切换的哨兵，会从要切换到的新master（salve => master）那里得到一个configuration epoch，这就是一个version号，每次切换的version号都必须是唯一的

如果第一个选举出的哨兵切换失败，那么其他哨兵，会等待failover-timeout时间，然后接替继续执行切换，此时会重新获取一个新的configuration epoch，作为新的version号

7 configuraiton传播

哨兵完成切换之后，会在自己本地更新生成最新的master配置，然后同步给其他哨兵

这里是通过pub/sub机制传递的

到了这里,之前提到的version号就很重要了，因为各种消息都是通过一个channel去发布和监听的，所以一个哨兵完成一次新的切换之后，新的master配置是跟着新的version号的

其他的哨兵也都是根据版本号的大小来更新自己的master配置的

1 sdown和odown转换机制

两种失败状态

1.1 概念

• sdown主观宕机
  一个哨兵自己觉得一个master宕机
• odown客观宕机
  quorum数量的哨兵都觉得一个master宕机

1.2 达成条件

• sdown
  一个哨兵ping一个master，超过is-master-down-after-milliseconds
• odown
  一个哨兵在指定时间内，收到了quorum指定数量的其他哨兵也认为那个master是sdown了，那么就认为是odown

2 自动发现机制

通过Redis的pub/sub实现哨兵互相之间的发现，每个哨兵都会往__sentinel__:hello这个channel发一个消息，此时所有其他哨兵都可消费到该消息，于是感知到其他哨兵的存在.

每隔2s，哨兵都会往自己监控的某个master+slaves对应的__sentinel__:hellochannel里发一个消息，内容为自己的host、ip和runid还有对该master的监控配置

每个哨兵也会去监听自己监控的每个master+slaves对应的__sentinel__:hello channel，然后去感知到同样在监听这个master+slaves的其他哨兵的存在

每个哨兵还会跟其他哨兵交换对master的监控配置，互相进行监控配置的同步

3 slave配置的自动纠正

哨兵会负责自动纠正slave的一些配置,比如

• slave要成为潜在的master候选人，哨兵会确保slave复制现有master的数据
• slave连接到了一个错误的master上，比如故障转移之后，那么哨兵会确保它们连接至正确的master

4 slave => master选举算法

若一个master被认为odown了，而且majority数量的哨兵都允许了主备切换，那么某个哨兵就会执行主备切换操作，此时首先要选举一个slave,会考虑slave的一些信息

• 跟master断开连接的时长
• slave优先级
• 复制offset
• run id

若一个slave跟master断开连接的时间已经超过down-after-milliseconds的10倍，外加master的宕机时长，那么slave就会被认为不适合选举为master

(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

  

 

  
1
 

接下来会对slave进行排序

1. 按照slave优先级进行排序，slave priority越低，优先级就越高
2. 如果slave priority相同，那么看replica offset，哪个slave复制了越多的数据，offset越靠后，优先级就越高
3. 如果上面两个条件都相同，那么选择一个run id比较小的那个slave

5 quorum和majority

每次一个哨兵要做主备切换，首先需要quorum数量的哨兵认为odown，然后选举出一个哨兵来做切换
该哨兵还得得到majority个哨兵的授权，才能正式执行切换

• 若quorum < majority
  比如5个哨兵，majority就是3，quorum设置为2，那么就3个哨兵授权就可以执行切换

• 若quorum >= majority
  那么必须quorum数量的哨兵都授权，比如5个哨兵，quorum是5，那么必须5个哨兵都同意授权，才能执行切换

6 configuration epoch

哨兵会监控一套Redis master+slave，并有相应的监控配置

执行切换的哨兵，会从要切换到的新master（salve => master）那里得到一个configuration epoch，这就是一个version号，每次切换的version号都必须是唯一的

如果第一个选举出的哨兵切换失败，那么其他哨兵，会等待failover-timeout时间，然后接替继续执行切换，此时会重新获取一个新的configuration epoch，作为新的version号

7 configuraiton传播

哨兵完成切换之后，会在自己本地更新生成最新的master配置，然后同步给其他哨兵

这里是通过pub/sub机制传递的

到了这里,之前提到的version号就很重要了，因为各种消息都是通过一个channel去发布和监听的，所以一个哨兵完成一次新的切换之后，新的master配置是跟着新的version号的

其他的哨兵也都是根据版本号的大小来更新自己的master配置的

文章来源: javaedge.blog.csdn.net，作者：JavaEdge.，版权归原作者所有，如需转载，请联系作者。

原文链接：javaedge.blog.csdn.net/article/details/94861678