Redis 高可用篇:你管这叫 Sentinel 哨兵集群原理

网友投稿 844 2023-05-27

Redis 高可用篇:你管这叫 Sentinel 哨兵集群原理

Redis 高可用篇:你管这叫 Sentinel 哨兵集群原理

概要我们知道「主从复制是高可用的基石」,从库宕机依然可以将请求发送给主库或者其他从库,但是 Master 宕机,只能响应读操作,写请求无法再执行。

所以主从复制架构面临一个严峻问题,主库挂了,无法执行「写操作」,无法自动选择一个 Slave 切换为 Master,也就是无法故障自动切换。

深夜与女朋友么么哒……(此处省略 10000 字),突然宕机,总不能提起裤子从床上爬起来手工进行主从切换,再通知其他程序员把地址重新改成新主库上线。

如此一折腾自己已被女友切换成前男友了,万万使不得。所以我们必须有一个高可用的方案,为此,Redis 官方提供一个高可用方案——哨兵(Sentinel)。

Redis 哨兵集群原理

开篇寄语

技术的迭代非常的快,但是从技术中沉淀下来的思维却是受益终生的。所以不要担心什么中年危机,那些担心中年危机的人通常很难成长起来。只要我们成长,只要我们的认知在不断突破,就不用担心中年危机,这个世界始终是需要那些优秀人才的。

什么是哨兵(Sentinel)“

65 哥:码哥,虽然我没女朋友,但是,未雨绸缪我要掌握这个哨兵模式,防止当深夜与女朋友么么哒被打扰,你快说说哨兵的实现原理吧。

”搭建实例采用三个哨兵形成集群,三个数据节点(一主两从)方式搭建,如下图所示:

Redis哨兵集群

65 哥你听过「武当派」创始人张三疯么?Redis 主从架构就好比一个武当,掌门人就是 Master。掌门人如果挂了,需要从武当七侠里面选举能人担当掌门人。这就需要一个部门能监控掌门人的生死和武当其他弟子的生命状态,并且能够通过投票从武当弟子中选举一个能者担任新掌门,接着再举行新闻发布会向世界宣布新掌门的信息。这个「部门」就是哨兵。

哨兵在选举新掌门会遇到以下几个问题:

如何判断掌门真的挂了,有可能假死;到底选择哪一个武当子弟作为新掌门?通过新闻发布会将新掌门的相关信息通知到所有武当弟子(slave 和 master)和整个武林(客户端)。

哨兵部门主要负责的任务是:监控整个武当、选择新掌门,通知整个武当和整个武林。

哨兵机制的主要任务

监控:持续监控 master 、slave 是否处于预期工作状态。自动切换主库:当 Master 运行故障,哨兵启动自动故障恢复流程:从 slave 中选择一台作为新 master。通知:让 slave 执行 replicaof ,与新的 master 同步;并且通知客户端与新 master 建立连接。

哨兵也是一个 Redis 进程,只是不对外提供读写服务,通常哨兵要配置成单数,为啥呢?且听「码哥字节」慢慢分析。

65 哥:那到底「哨兵」这个神秘部门是如何实现这三个能力的?

我们先从全局观看哨兵,简要的了解整个运作流程,接着再针对每一个任务详细分析。首先从监控开始…...

监控

Sentinel 只是武当弟子中的特殊部门,在默认情况下,Sentinel 通过飞鸽传书以每秒一次的频率向所有武当弟子、掌门与哨兵(包括 Master、Slave、其他 Sentinel 在内)发送 PING 命令,如果 slave 没有在在规定时间内响应「哨兵」的 PING 命令,「哨兵」就认为这哥们可能嗝屁了,就会将他记录为「下线状态」;

假如 master 掌门没有在规定时间响应 「哨兵」的 PING 命令,哨兵就判定掌门下线,开始执行「自动切换 master 掌门」的流程。

PING 命令的回复有两种情况:

有效回复:返回 +PONG、-LOADING、-MASTERDOWN 任何一种;无效回复:有效回复之外的回复,或者指定时间内返回任何回复。

65 哥:哨兵如何判断「掌门」嗝屁呢?掌门诈尸咋办?

为了防止掌门「假死」,「哨兵」设计了「主观下线」和「客观下线」两种暗号。

主观下线

哨兵利用 PING 命令来检测掌门、 slave 的生命状态。如果是无效回复,哨兵就把这个哥们标记为「主观下线」。检测到的是武当小弟,也就是 slave 角色。那么就直接标记「主观下线」。

因为 master 掌门还在,slave 的嗝屁对整个武当影响不大。依然可以对外开会,比武论剑、吃香喝辣…...

如果检测到是 master 掌门完蛋,这时候哨兵不能这么简单的标记「主观下线」,开启新掌门选举。

因为有可能出现误判,掌门并没有嗝屁,一旦启动了掌门切换,后续的选主、通知开发布会,slave 花时间与新 master 同步数据都会消耗大量资源。

所以「哨兵」要降低误判的概率,误判一般会发生在集群网络压力较大、网络拥塞,或者是主库本身压力较大的情况下。

既然一个人容易误判,那就多个人一起投票判断。哨兵机制也是类似的,采用多实例组成的集群模式进行部署,这就是哨兵集群。引入多个哨兵实例一起来判断,就可以避免单个哨兵因为自身网络状况不好,而误判主库下线的情况。

同时,多个哨兵的网络同时不稳定的概率较小,由它们一起做决策,误判率也能降低。

客观下线

判断 master 是否下线不能只有一个「哨兵」说了算,只有过半的哨兵判断 master 已经「主观下线」,这时候才能将 master 标记为「客观下线」,也就是说这是一个客观事实,掌门真的嗝屁了,华佗再世也治不好了。

只有 master 被判定为「客观下线」,才会进一步触发哨兵开始主从切换流程。

客观下线

主观下线与客观下线的区别

简单来说,主观下线是哨兵自己认为节点宕机,而客观下线是不但哨兵自己认为节点宕机,而且该哨兵与其他哨兵沟通后,达到一定数量的哨兵都认为该哥们嗝屁了。

这里的「一定数量」是一个法定数量(Quorum),是由哨兵监控配置决定的,解释一下该配置:

# sentinel monitor     # 举例如下: sentinel monitor mymaster 127.0.0.1 6379 2

这条配置项用于告知哨兵需要监听的主节点:

sentinel monitor:代表监控。mymaster:代表主节点的名称,可以自定义。192.168.11.128:代表监控的主节点 ip,6379 代表端口。2:法定数量,代表只有两个或两个以上的哨兵认为主节点不可用的时候,才会把 master 设置为客观下线状态,然后进行 failover 操作。

「客观下线」的标准就是,当有 N 个哨兵实例时,要有 N/2 + 1 个实例判断 master 为「主观下线」,才能最终判定 Master 为「客观下线」,其实就是过半机制。

自动切换主库

65 哥:既然判断 master 客观下线了,那就要从选出一个新掌门人了吧。

「哨兵」的第二个任务,选择新 master 掌门。需要从武当弟子中按照一定规则选择一个牛逼人物作为新掌门,完成选任掌门后,新 master 带领众弟子一起吃香喝辣。

按照一定的 「筛选条件」 + 「打分」 策略,选出「最强王者」担任掌门,也就是通过一些条件海选过滤一些「无能之辈」,接着将通过海选的靓仔全都打分排名,将最高者选为新 master。

如图所示:

新master选择

网络经常断开的靓仔也不可取,你想,即使变成 master,可是很快网络出了故障,又得重新选择新 master,这不闹着玩么,得排除掉!

筛选条件

65 哥:那都有哪些筛选条件呀?

从库当前在线状态,下线的直接丢弃;

评估之前的网络连接状态 down-after-milliseconds \* 10:如果从库总是和主库断连,而且断连次数超出了一定的阈值(10 次),我们就有理由相信,这个从库的网络状况并不是太好,就可以把这个从库筛掉了。

打分

过滤掉不合适的 slave 之后,则进入打分环节。打分会按照三个规则进行三轮打分,规则分别为:

slave 优先级,通过 slave-priority 配置项,给不同的从库设置不同优先级(后台有人没办法),优先级高的直接晋级为新 master 掌门。slave_repl_offset与 master_repl_offset进度差距(谁的武功与之前掌门的功夫越接近谁就更牛逼),如果都一样,那就继续下一个规则。其实就是比较 slave 与旧 master 复制进度的差距;slave runID,在优先级和复制进度都相同的情况下,ID 号最小的从库得分最高,会被选为新主库。(论资排辈,根据 runID 的创建时间来判断,时间早的上位);

通知

65 哥:为啥还要召开新闻发布会呢?

重新选举新 master 掌门这种事情,何等大事,怎能不告知天下。再者其他 slave 弟子也要知道新掌门是谁,一起追随新掌门吃香喝辣大保健。

最后一个任务,「哨兵」将新 「master 掌门」的连接信息发送给其他 slave 武当弟子,并且让 slave 执行 replacaof 命令,和新「master 掌门」建立连接,并进行数据复制学习新掌门的所有武功。

除此之外,「哨兵」还需要将新掌门的连接信息通知整个武林(客户端),使得让所有想拜访、讨教的人能找到新任掌门,这样诸多事宜才能交给新掌门做决定(将读写请求转移到新 master)。

哨兵的主要任务与实现目标

哨兵执行任务与目标

哨兵集群工作原理

「哨兵」部门并不是一个人,多个人共同组成一个「哨兵集群」,即使有一些「哨兵」被老王打死了,其他的「哨兵」依然可以共同协作完成监控、新掌门选举以及通知 slave 、master 以及每一个武林人士(客户端)。

在配置哨兵集群的时候,哨兵配置中只设置了监控的 master IP 和 port,并没有配置其他哨兵的连接信息。

sentinel monitor    

哨兵之间是如何知道彼此的?如何知道 slave 并监控他们的?由哪一个「哨兵」执行主从切换呢?

带着这些问题,跟着「码哥字节」一起追本溯源,深入哨兵集群心脏。

pub/sub 实现哨兵间通信和发现 slave

65 哥:哨兵之间是如何知道彼此的?

哨兵之间可以相互通信约会搞事情,主要归功于 Redis 的 pub/sub 发布/订阅机制。

哨兵与 master 建立通信,利用 master 提供发布/订阅机制发布自己的信息,比如身高体重、是否单身、IP、端口……

master 有一个 __sentinel__:hello 的专用通道,用于哨兵之间发布和订阅消息。这就好比是 __sentinel__:hello 微信群,哨兵利用 master 建立的微信群发布自己的消息,同时关注其他哨兵发布的消息。

Redis pub/sub 机制

当多个哨兵实例都在主库上做了发布和订阅操作后,它们之间就能知道彼此的 IP 地址和端口,从而相互发现建立连接。

65 哥:哨兵之间虽然建立连接了,但是还需要和 slave 建立连接,不然没法监控他们呀,如何知道 slave 并监控他们的?

的确,哨兵之间建立连接形成集群还不够,还需要跟 slave 建立连接,不然没法监控他们,无法对主从库进行心跳判断。

除此之外,如果发生了主从切换也得通知 slave 重新跟新 master 建立连接执行数据同步。关于主从架构数据同步原理可移步《Redis 高可用篇:你管这叫主从架构数据一致性同步》。

关键还是利用 master 来实现,哨兵向 master 发送 INFO 命令, master 掌门自然是知道自己门下所有的 salve 小弟的。所以 master 接收到命令后,便将 slave 列表告诉哨兵。

哨兵根据 master 响应的 slave 名单信息与每一个 salve 建立连接,并且根据这个连接持续监控哨兵。

如图所示,哨兵 2 向 Master 发送 INFO 命令,Master 就把 slave 列表返回给哨兵 2,哨兵 2 便根据 slave 列表连接信息与每一个 slave 建立连接,并基于此连接实现持续监控。

剩下的哨兵也同理基于此实现监控。

INFO命令获取slave信息

选择哨兵执行主从切换

65 哥:master 嗝屁了以后,哨兵这么多,那到底让哪一个哨兵来执行新 master 切换呢?

这个跟哨兵判断 master “客观下线”类似,也是通过投票的方式选出来的。

任何一个哨兵判断 master “主观下线”后,就会给其他哨兵基友发送 is-master-down-by-addr 命令,好基友则根据自己跟 master 之间的连接状况分别响应 Y 或者 N ,Y 表示赞成票, N 就是反对。

如果某个哨兵获得了大多数哨兵的“赞成票”之后,就可以标记 master 为 “客观下线”,赞成票数是通过哨兵配置文件中的 quorum 配置项设定。

sentinel monitor    

比如一共 3 个哨兵组成集群,那么 quorum 就可以配置成 2,当一个哨兵获得了 2 张赞成票,就可以标记 master “客观下线”,当然这个票包含自己的那一票。

获得多数赞成票的哨兵可以向其他哨兵发送命令,申明自己想要执行主从切换。并让其他哨兵进行投票,投票过程就叫做 “Leader 选举”。

想要成为 “Leader”没那么简单,得有两把刷子。需要满足以下条件:

获得其他哨兵基友过半的赞成票;赞成票的数量还要大于等于配置文件的 quorum 的值。

如果哨兵集群有 2 个实例,此时,一个哨兵要想成为 Leader,必须获得 2 票,而不是 1 票。所以,如果有个哨兵挂掉了,那么,此时的集群是无法进行主从库切换的。因此,通常我们至少会配置 3 个哨兵实例。

这也是为啥哨兵集群部署成单数的原因,双数的话多余浪费。

选举流程如下图所示:

Redis哨兵执行主从切换

通过 pub/sub 实现客户端事件通知

65 哥:新 master 选出来了,要怎么公示天下呢?

当然是召开新闻发布会呀,邀请消息相关类型的媒体报道传播,感兴趣的人自然就去关注订阅相关事件,并根据事件做出行动。

在 Redis 也是类似,通过 pub/sub 机制发布不同事件,让客户端在这里订阅消息。客户端可以订阅哨兵的消息,哨兵提供的消息订阅频道有很多,不同频道包含了主从库切换过程中的不同关键事件。

也就是在不同的“微信群”发布不同的事件,让对该事件感兴趣的人进群即可。

master 下线事件

+sdown:进入“主观下线”状态;-sdown:退出“主观下线”状态;+odown:进入“客观下线”状态;-odown:退出“客观下线”状态;

slave 重新配置事件

+slave-reconf-sent:哨兵发送 replicaof 命令重新配置从库;+slave-reconf-inprog:slave 配置了新 master,但是尚未进行同步;+slave-reconf-done:slave 配置了新 master,并与新 master 完成了数据同步;

新主库切换

+switch-master:master 地址发生了变化。

知道了这些频道之后,就可以让客户端从哨兵这里订阅消息了。客户端读取哨兵的配置文件后,可以获得哨兵的地址和端口,和哨兵建立网络连接。

然后,我们可以在客户端执行订阅命令,来获取不同的事件消息。

举个栗子:如下指令订阅“所有实例进入客观下线状态的事件”

SUBSCRIBE +odown

注意事项与配置说明

发现了没,Redis 的 pub/sub 发布订阅机制尤其重要,有了 pub/sub 机制,哨兵和哨兵之间、哨兵和从库之间、哨兵和客户端之间就都能建立起连接了,各种事件的发布也是通过这个机制实现。

down-after-milliseconds

Sentinel 配置文件中的 down-after-milliseconds 选项指定了 Sentinel 判断实例进入主观下线所需的时间长度:如果一个实例在 down-after-milliseconds 毫秒内,连续向 Sentinel 返回无效回复,那么 Sentinel 会修改这个实例所对应数据,以此来表示这个实例已经进入主观下线状态。

要保证所有哨兵实例的配置是一致的,尤其是主观下线的判断值 down-after-milliseconds。因为这个值在不同的哨兵实例上配置不一致,导致哨兵集群一直没有对有故障的主库形成共识,也就没有及时切换主库,最终的结果就是集群服务不稳定。

down-after-milliseconds * 10

down-after-milliseconds 是我们认定主从库断连的最大连接超时时间。如果在 down-after-milliseconds 毫秒内,主从节点都没有通过网络联系上,我们就可以认为主从节点断连了。如果发生断连的次数超过了 10 次,就说明这个从库的网络状况不好,不适合作为新主库。

总结

哨兵主要任务

Redis 哨兵机制是实现 Redis 不间断服务的高可用手段之一。主从架构集群的数据同步,是数据可靠的基础保障;主库宕机,自动执行主从切换是服务不间断的关键支撑。

Redis 哨兵机制实现了主从库的自动切换,再也不怕跟女盆友么么哒的时候 master 宕机了:

监控 master 与 slave 运行状态,判断是否客观下线;master 客观下线后,选择一个 slave 切换成 master;通知 slave 和客户端新 master 信息。

哨兵集群原理

为了避免单个哨兵故障后无法进行主从切换,以及为了减少误判率,又引入了哨兵集群;哨兵集群又需要有一些机制来支撑它的正常运行:

基于 pub/sub 机制实现哨兵集群之间的通信;基于 INFO 命令获取 slave 列表,帮助 哨兵与 slave 建立连接;通过哨兵的 pub/sub,实现了与客户端和哨兵之间的事件通知。

主从切换,并不是随意选择一个哨兵就可以执行,而是通过投票仲裁,选择一个 Leader,由这个 Leader 负责主从切换。

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:数据库 | “分库分表”,还能这么玩!
下一篇:一篇带给你MySQL锁机制
相关文章