Redis高可用之哨兵机制实现细节

Redis高可用之哨兵机制实现细节

本文来自我的 technotes 1 Redis篇,欢迎你常来逛逛。

正文

在上一篇的文章《Redis高可用全景一览》中,我们学习了 Redis 的高可用性。高可用性有两方面含义:一是服务少中断,二是数据少丢失。主从库模式和哨兵保证了服务少中断,AOF 日志和 RDB 快照保证了数据少丢失。

并且我们学习了哨兵三个职责,分别是:监控、选主(选择主库)和通知。今天我们就来详细学习一下。

首先呐,在哨兵启动前,我们要对哨兵进行配置。Redis 源码中包含了一个名为 sentinel.conf 2 的文件,该文件中部分配置如下:

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000

第一行配置指示 Sentinel 去监视一个名为 mymaster 的主服务器, 这个主服务器的 IP 地址为 127.0.0.1 , 端口号为 6379 , 而将这个主服务器判断为失效至少需要 2 个 Sentinel 同意 。

可以看到,我们仅仅设置了主库的 IP 和端口。并没有配置其他哨兵的连接信息啊,这些哨兵实例既然都不知道彼此的地址,又是怎么组成集群的呢?

哨兵实例之间可以相互发现,要归功于 Redis 提供的 pub/sub 机制,也就是发布 / 订阅机制。在主从集群中,主库上有一个名为__sentinel__:hello的频道,不同哨兵就是通过它来相互发现,实现互相通信的。

一、哨兵集群的组成

每隔2秒, 每个 Sentinel 节点就会向 Redis 数据节点的__sentinel__:hello频道上发送该 Sentinel 节点对于主节点的判断以及当前 Sentinel 节点的信息。

哨兵间的通信

举个例子。在上图中,哨兵 1 把自己的 IP(172.16.19.3)和端口(26579)发布到__sentinel__:hello频道上,哨兵 2 和 3 订阅了该频道。那么此时,哨兵 2 和 3 就可以从这个频道直接获取哨兵 1 的 IP 地址和端口号。

然后,哨兵 2、3 可以和哨兵 1 建立网络连接。通过这个方式,哨兵 2 和 3 也可以建立网络连接,这样一来,哨兵集群就形成了。它们相互间可以通过网络连接进行通信,比如说对主库有没有下线这件事儿进行判断和协商。

哨兵除了彼此之间建立起连接形成集群外,还需要和从库建立连接。这是因为,在哨兵的监控任务中,它需要对主从库都进行心跳判断,而且在主从库切换完成后,它还需要通知从库,让它们和新主库进行同步。

那么,哨兵又是如何知道从库的 IP 地址和端口的呢?

二、获取从节点信息

这是由哨兵向主库发送 INFO 命令来完成的。就像下图所示,哨兵 2 给主库发送 INFO 命令,主库接受到这个命令后,就会把从库列表返回给哨兵。接着,哨兵就可以根据从库列表中的连接信息,和每个从库建立连接。哨兵 1 和 3 也可以通过相同的方法和从库建立连接。

获取从节点信息

下面是在一个主节点上执行 info 命令的结果片段:

# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=4917,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=4917,lag=1

之后,哨兵会在这个连接上持续地对从库进行监控。每隔10秒, 哨兵节点就会向主节点和从节点发送 info 命令,获取集群最新的拓扑结构。这样,当有新的从节点加入时就可以立刻感知出来。节点不可达或者选定新主库后,也可以通过 info 命令实时更新节点拓扑信息。

执行info命令

有了集群的信息,哨兵终于可以开始它的工作了。第一项职责:判断主从库是否下线。

三、如何判断主从库下线?

3.1 定时执行 ping 命令

哨兵进程在运行时,每隔1秒,会向主节点、 从节点、 其余 Sentinel 节点发送一条 ping 命令,检测它们是否仍然在线运行。如果主、从库没有在规定时间内响应哨兵的 ping 命令,哨兵就会把它标记为「下线状态」。

执行ping命令

如果检测的是主库,那么,哨兵还不能简单地开启主从切换。因为很有可能存在这么一个情况:那就是哨兵误判了,其实主库并没有故障。

误判一般会发生在集群网络压力较大、网络拥塞,或者是主库本身压力较大的情况下。一旦哨兵误判,启动了主从切换,后续的选主和通知操作都会带来额外的计算和通信开销。

那怎么减少误判呢?

3.2 主观下线和客观下线

哨兵机制通常会采用多实例组成的集群模式进行部署,这也被称为哨兵集群。引入多个哨兵实例一起来判断,就可以避免单个哨兵因为自身网络状况不好,而误判主库下线的情况。同时,多个哨兵的网络同时不稳定的概率较小,由它们一起做决策,误判率也能降低。

主观下线和客观下线

还记得我在文章开头给出的 sentinel.conf 配置吗?

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000

down-after-milliseconds选项就是 Sentinel 认为服务器已经断线的临界阈值。

如果服务器在该毫秒数之内, 没有返回 Sentinel 发送的 ping 命令的回复, 或者返回一个错误, 那么 Sentinel 将这个服务器标记为主观下线(subjectively down,简称 SDOWN )。

如果没有足够数量的 Sentinel 同意主库已经下线, 当主库重新向 Sentinel 的 PING 命令返回有效回复时, 主库的主观下线状态就会被移除。而如果超出 2 个 Sentinel 都将主库标记为主观下线之后, 主库才会被标记为客观下线(objectively down, 简称 ODOWN )。哨兵就要开始下一个决策过程了,即从许多从库中,选出一个从库来做新主库。

四、如何选定新主库?

4.1 初步筛选

设想一下,如果在选主时,一个从库正常运行,我们把它选为新主库开始使用了。可是,很快它的网络出了故障,此时,我们就又得重新选主了。这显然不是我们期望的结果。所以,在选主时,除了要检查从库的当前在线状态,还要判断它之前的网络连接状态。如果从库总是和主库断连,而且断连次数超出了一定的阈值,我们就有理由相信,这个从库的网络状况并不是太好,就可以把这个从库筛掉了。

初步筛选

具体怎么判断呢?你使用配置项 down-after-milliseconds * 10。其中,down-after-milliseconds 是我们认定主从库断连的最大连接超时时间。如果在 down-after-milliseconds 毫秒内,主从节点都没有通过网络联系上,我们就可以认为主从节点断连了。如果发生断连的次数超过了 10 次,就说明这个从库的网络状况不好,不适合作为新主库。

这样我们就过滤掉了不适合做主库的从库,完成了筛选工作。

接下来就要给剩余的从库打分了。我们可以分别按照三个规则依次进行三轮打分,这三个规则分别是从库优先级、从库复制进度以及从库 ID 号。

4.2 三轮打分

第一轮:优先级最高的从库得分高。

用户可以通过 slave-priority 配置项,给不同的从库设置不同优先级。比如,你有两个从库,它们的内存大小不一样,你可以手动给内存大的实例设置一个高优先级。

第二轮:和旧主库同步程度最接近的从库得分高。

这个规则的依据是,如果选择和旧主库同步最接近的那个从库作为主库,那么,这个新主库上就有最新的数据。

如何判断从库和旧主库间的同步进度呢?

主从库同步时有个命令传播的过程。在这个过程中,主库会用 master_repl_offset 记录当前的最新写操作在 repl_backlog_buffer 中的位置,而从库会用 slave_repl_offset 这个值记录当前的复制进度。

主从库同步时有个命令传播的过程。在这个过程中,主库会用 master_repl_offset 记录当前的最新写操作在 repl_backlog_buffer 中的位置,而从库会用 slave_repl_offset 这个值记录当前的复制进度。

如下图所示,从库 2 就应该被选为新主库。

第三轮:ID 号小的从库得分高。

每个实例都会有一个 ID,这个 ID 就类似于这里的从库的编号。目前,Redis 在选主库时,有一个默认的规定:在优先级和复制进度都相同的情况下,ID 号最小的从库得分最高,会被选为新主库。

到这里,新主库就被选出来了,接下来就是将从库升级为主库。但是问题又来了,这么多哨兵,该由谁来执行主从切换操作呢?

4.3 由哪个哨兵执行主从切换?

任何一个哨兵实例只要自身判断主库“主观下线”后,就会向其他 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为主库已下线。接着,其他哨兵实例会根据自己和主库的连接情况,做出 Y 或 N 的响应,Y 相当于赞成票,N 相当于反对票。

此时,这个哨兵就可以再给其他哨兵发送命令,表明希望由自己来执行主从切换,并让所有其他哨兵进行投票。这个投票过程称为“Leader 选举”。选举出来的 Leader 就是最终执行主从切换的哨兵。

例如,现在有 3 个哨兵,quorum 配置的是 2,我们来看一下选举的过程是什么样的。

在 T1 时刻,S1 判断主库为“客观下线”,它想成为 Leader,就先给自己投一张赞成票,然后分别向 S2 和 S3 发送命令,表示要成为 Leader。

在 T2 时刻,S3 判断主库为“客观下线”,它也想成为 Leader,所以也先给自己投一张赞成票,再分别向 S1 和 S2 发送命令,表示要成为 Leader。

在 T3 时刻,S1 收到了 S3 的 Leader 投票请求。因为 S1 已经给自己投了一票 Y,所以它不能再给其他哨兵投赞成票了,所以 S1 回复 N 表示不同意。同时,S2 收到了 T2 时 S3 发送的 Leader 投票请求。因为 S2 之前没有投过票,它会给第一个向它发送投票请求的哨兵回复 Y,给后续再发送投票请求的哨兵回复 N,所以,在 T3 时,S2 回复 S3,同意 S3成为 Leader。

在 T4 时刻,S2 才收到 T1 时 S1 发送的投票命令。因为 S2 已经在 T3 时同意了 S3 的投票请求,此时,S2 给 S1 回复 N,表示不同意 S1 成为 Leader。发生这种情况,是因为 S3 和 S2 之间的网络传输正常,而 S1 和 S2 之间的网络传输可能正好拥塞了,导致投票请求传输慢了。

在 T5 时刻,S1 得到的票数是来自它自己的一票 Y 和来自 S2 的一票 N。而 S3 除了自己的赞成票 Y 以外,还收到了来自 S2 的一票 Y。此时,S3 不仅获得了半数以上的 Leader 赞成票,也达到预设的 quorum 值(quorum 为 2),所以它最终成为了 Leader。

接着,S3 会开始执行选主操作,而且在选定新主库后,会给其他从库和客户端通知新主库的信息。

五、将新主库通知给从库和客户端

通过上文的学习,我们知道哨兵可以向主库发送 INFO 命令,来获取从库的 IP 地址和端口。

但是,哨兵不能只和主、从库连接。因为,主从库切换后,客户端也需要知道新主库的连接信息,才能向新主库发送请求操作。所以,哨兵还需要把新主库的信息告诉客户端。

那怎么把新主库的信息告诉客户端呢?

5.1 基于 pub/sub 机制的客户端事件通知

从本质上说,哨兵就是一个运行在特定模式下的 Redis 实例,只不过它并不服务请求操作,只是完成监控、选主和通知的任务。所以,每个哨兵实例也提供 pub/sub 机制,客户端可以从哨兵订阅消息。

下图示中是一些重要的频道,以及涉及的几个关键事件。更多的频道你可以在文末链接 3 中查看。

客户端从主库读取哨兵的配置文件后,可以获得哨兵的地址和端口,和哨兵建立网络连接。

当哨兵把新主库选择出来后,客户端就会看到下面的 switch-master 事件。这个事件表示主库已经切换了,新主库的 IP 地址和端口信息已经有了。这个时候,客户端就可以用这里面的新主库地址和端口进行通信了。

switch-master <master name> <oldip> <oldport> <newip> <newport>

小结

至此,哨兵的工作职责及细节我们就学习完了。我整理了本文知识消化链路,如下。

在sentinel.conf中配置哨兵
-> 没有配置其他哨兵ip,怎么组成集群的?
-> 哨兵是怎么知道从库的IP和端口的?
-> 职责1:如何判断主从库下线了?
-> 职责2:如何选定新主库?
-> 由哪个哨兵执行主从切换?
-> 职责3:如何把新主库告诉客户端?

更多技术干货,我会在后面的内容里继续分享,敬请关注。公众号「杨同学technotes」,欢迎技术交流。

文中所提及的链接

1 https://www.dbses.cn/technotes
2 https://github.com/redis/redis/blob/unstable/sentinel.conf
3 https://redis.io/docs/management/sentinel/

附 Redis 文档

http://www.redis.cn/topics/sentinel.html
https://redis.io/docs/management/sentinel

本站文章资源均来源自网络,除非特别声明,否则均不代表站方观点,并仅供查阅,不作为任何参考依据!
如有侵权请及时跟我们联系,本站将及时删除!
如遇版权问题,请查看 本站版权声明
THE END
分享
二维码
海报
Redis高可用之哨兵机制实现细节
在上一篇的文章《Redis高可用全景一览》中,我们学习了 Redis 的高可用性。高可用性有两方面含义:一是服务少中断,二是数据少丢失。主从库模式和哨兵保证了服...
<<上一篇
下一篇>>