搞懂Redis (八) - 哨兵机制

搞懂Redis (八) - 哨兵机制,第1张

哨兵的核心功能是主节点的自动故障转移

下图是一个典型的哨兵集群监控的逻芦配辑图

Redis Sentinel包含了若拍册干个Sentinel 节点,这样做也带来了两个好处:

1、 对于节点的故障判断是由多个sentinel节点共同完成,这样可以有效地防止误判

2、即使个别sentinel节点不可用,整个sentinel集群依然是可用的

哨兵实现了以下功能:

1、监控:每个sentinel节点会对数据节点(Redis master/slave节点)和其余sentinel节点进行监控

2、通知:sentinel节点会将故障转移的结果通知给应用方

3、故障转移:实现slave晋升为master,并维护后续正确的主从关系

4、配置中心:在Redis sentinel模式中,客户端在初始化的时候连接的是sentinel节点集合,从中获取主节点信息

其中,监控和自动故障转移功能,使得哨兵可以及时发现主节点故障并完成转移;而配置中心和通知功能,则需要在与客户端的交互中才能体现

1、原理

监控

sentinel节点需要监控master、slave以及其他sentinel节点的状态。这一过程是通过Redis的pub\sub系统实现的。Redis sentinel一共有三个定时监控任务,完成对各个节点发现和监控:

主观/客观下线

主观下线

每个sentinel节点,每隔1s会对数据节点发送ping命令做心跳检测,当这些节点超过down-after-milliseconds没有进行有效回复时,sentinel节点会对该节点做失败判定,这叫主观下线

客观下线

客观下线,是指当大多数sentinel节点都认为master节点宕机了,那这个判定就是客观的,叫客观下线。

那大多数是指什么呢? 其实就是分布式协调中的quorum判定啦,大多数就是指半数。 如哨兵数量是5,那大多数就是5/2+1=3个,哨兵数量是10大多数就是10/2+1=6个。

注:sentinel节点的数量至少为3个,否则不满足quorum判定条件

哨兵选举

如果发生了客观袭哗宏下线,那哨兵节点会选举出一个leader来进行实际的故障转移工作。Redis使用了Raft算法来实现哨兵领导者选举,大致思路如下:

故障转移

选举出的leader sentinel节点将负责故障转移,也就是进行master/slave节点的主从切换。故障转移,首先要从slave节点中筛选出一个作为新的master,主要考虑以下slave信息

注:Leader sentinel 节点,会从新的master节点那里得到一个configuration epoch,本质是个version版本号,每次主从切换的version号都必须是唯一的。其他的哨兵都是根据version来更新自己的master配置

sentinal,中文名是哨兵

哨兵是redis集群架构中非常重要的一个组件,主要功能如下:

(1)集群监控,负责监控redis master和slave进程是否正常工作

(2)消息通知,如果某个redis实例有故障,那么哨兵负责发送消息作为报警通知给管理员

(3)故障转移,如果master node挂掉了,会自动转移到slave node上

(4)配置中心,如果故障转移发生了,通知client客户端新的master地址

哨兵本身也是分布式的,作为一个哨兵集群去运行,互相协同工作

(1)故障转移时,判断一个master node是宕机了,需要大部分的哨兵都同意才行,涉及到了分布式选举的问题

(2)即使部分哨兵节点挂掉了,哨兵集群还是能正常工作的,因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的,这样就无法做到高可用了。

(1)哨兵至少需要3个实例,来保证自己的健壮性

(2)哨兵 + redis主从的部署架构,是不会保证数据零丢失的,只能保证redis集群的高可用性

(3)对于哨兵 + redis主从这种复杂的部署架构,尽量在测试环境和生产环境,都进行充足的测试和演练

1 哨兵集群必须部署2个以上节点

如果哨兵集群仅仅部署了个2个哨兵实例,quorum=1

Configuration: quorum = 1

master宕机,s1和s2中只册冲慧要有1个哨兵认为master宕机就可以还行切换,同时s1和s2中会选举出一个哨兵来执行故障转移。

同时这个时候,需要majority,也就是大多数哨兵都是运行的,2个哨兵的majority就是2(2的majority=2,3的majority=2,5的majority=3,4的majority=2),2个哨兵都运行着,就可以允许执行故障转移。

但是如果整个M1和S1运行的机器宕机了,那么哨兵只有1个了,此时就没有majority来允许执行故障转移,虽然另判镇外一台机器还有一个R1,但是故障转移不会执行。

2 经典的哨兵集群

Configuration: quorum = 2,majority

如果M1所在机器宕机了,那么三个哨兵还剩下2个,S2和S3可以一致认为master宕机,然后选举出一个来执行故障转移。

同时3个哨兵的majority是2,所以还剩下的2个哨兵运行着,就可以允许执行故障转移。

sdown和odown两种失败状态

sdown是主观宕机,就一个哨兵如果自己觉得一个master宕机了,那么就是主观宕机。

odown是客观宕机,如果quorum数量的哨兵都觉得一个master宕机了,那么就是客观宕机。

sdown达成的条件很简单,如果一个哨兵ping一个master,超过了is-master-down-after-milliseconds指定的毫秒数之后,就主观认为master宕机。

sdown到odown转换的条件很简单,如果一个哨兵在指定时间内,收到了quorum指定数量的其他哨兵也认为那个master是sdown了,那么就认为是odown了,客观认为master宕机。

哨兵互相之间的发现,是通过redis的pub/sub系统实现的,每个哨兵都会往 sentinel :hello这个channel里发送一个消息,这时候所有其他哨兵都可以消费到这个消息,并感知到其他的哨兵的存在

每隔两秒钟,每个哨兵都会往自己监控的某个master+slaves对应的 sentinel :hello channel里发送一个消息,内容是自己的host、ip和州答runid还有对这个master的监控配置。

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

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

哨兵会负责自动纠正slave的一些配置,比如slave如果要成为潜在的master候选人,哨兵会确保slave在复制现有master的数据如果slave连接到了一个错误的master上,比如故障转移之后,那么哨兵会确保它们连接到正确的master上

如果一个master被认为odown了,而且majority哨兵都允许了主备切换,那么某个哨兵就会执行主备切换 *** 作,此时首先要选举一个slave来

会考虑slave的一些信息

(1)跟master断开连接的时长

(2)slave优先级

(3)复制offset

(4)run id

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

(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

接下来会对slave进行排序

(1)按照slave优先级进行排序,slave priority越低,优先级就越高

(2)如果slave priority相同,那么看replica offset,哪个slave复制了越多的数据,offset越靠后,优先级就越高

(3)如果上面两个条件都相同,那么选择一个run id比较小的那个slave

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

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

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

哨兵会对一套redis master+slave进行监控,有相应的监控的配置

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

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

哨兵完成切换之后,会在自己本地更新生成最新的master配置,然后同步给其他的哨兵,就是通过之前说的pub/sub消息机制

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

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


欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/yw/8212793.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-14
下一篇 2023-04-14

发表评论

登录后才能评论

评论列表(0条)

保存