美文网首页
五、Redis 的哨兵机制与哨兵集群

五、Redis 的哨兵机制与哨兵集群

作者: 从不中二的忧伤 | 来源:发表于2021-06-09 10:31 被阅读0次

    之前提到 Redis 有主从库集群机制,以减轻主库的请求压力,实现 Redis 的高可用性。 并且,我们已经知道,请求的写操作只会在主库上执行,然后主库再同步到各个从库上。 当从库挂掉时,还有主库或者其他从库可以提供读操作,可是,当主库挂掉以后,写操作该如何继续执行呢?

    实际上,当主库挂掉了,会有其他从库切换成主库,继续执行写操作,将数据同步给其他从库。

    那么,这个从库切换成主库的过程,就需要考虑以下几个问题:
    1、主库真的挂了吗?
    2、选取哪个从库切换成主库?
    3、某个从库切换成主库后,怎样通知其他从库?

    Redis 的哨兵机制,就在此时体现出作用了,Redis 就是通过哨兵机制检测主库是否挂掉、选取从库切换为主库、将新主库信息通知给其他从库的。

    Redis 的哨兵机制

    哨兵实际上就是一个运行在特殊模式下的 Redis 进程,主从库实例运行的同时,哨兵进程也在运行,哨兵主要负责三个任务:监控、选择主库、通知从库变更

    监控
    监控就是指,哨兵会周期性地向主从库发起心跳检测,确认主从库是否在线,然后标记主从库的下线状态。

    下线状态分为 “主观下线”和“客观下线”,如果主从库在规定时间内,没有响应哨兵的心跳较检测,那么哨兵就将此主、从库标记为“主观下线” 。

    但是,需要注意的是,网络环境是复杂的,很有可能这个 Redis 实例是因为其他原因,没有响应哨兵的心跳检测,但实际上这个Redis 实例是正常运行的。 这个时候,就必须说到 Redis 的哨兵集群 —— 有一群哨兵对 Redis 实例进行心跳检测,某个哨兵检测到某个 Redis 实例下线,可以将其标记为“主观下线”,但是,只有超过一定数量的哨兵,都认为此实例“主观下线”了,这个 Redis 实例才能被标记为 “客观下线”。

    对于从库来说,只要标记为 “主观下线”,就可以判断其已经下线了,因为从库下线不会对 Redis 整体产生太大的影响。

    而对于主库来说,必须将其标记为 “客观下线”,也就是有一定数量的哨兵都认为 主库 已经“主观下线”了,才能认为主库挂了,从而进行下一步的主从库切换。

    如何选取新主库?
    在主库被标记为 “客观下线” 后,就应该选举某个从库切换为主库了。 一般来说,新主库的选举包括两部分 “筛选 + 打分”

    • 筛选:指的是从库必须正常在线运行,才能被选举为主库。筛选时,除了判断从库当前的连接状态,还应该判断之前的网络连接状态。 只有当前,和之前的网络连接状态都良好,这个从库才有资格被选为主库。

    • 打分:在筛选完成后,要从剩下的从库中,依次进行三轮打分,分别是 从库优先级、从库复制进度以及从库ID号。 只要在某一轮中,选出了最高分的从库,那么这个从库直接成为新主库。
      1、根据从库优先级打分
      从库上可以根据 slave-priority 配置项,配置该从库的优先级。 这个优先级的设置,可以根据实例本身的机器内存、磁盘、CPU配置设置这个优先级。
      2、根据旧主库同步程度最接近的从库打分
      主库同步数据给从库的时候,会带有一个 offset 标记同步进度。 实际上,只需要比较各个从库的 offset,这个数据越大,说明越接近主库数据,那么在这一轮打分越高。
      3、ID号小的从库得分高
      这个实际上就是一个托底逻辑,每个实例都会有一个ID,在前两轮都无法确定出主库的情况下,ID 号最小的从库最分最高。

    经过网络情况的筛选和上面三轮的打分,新主库就被选举出来了。

    把新主库的信息通知给从库
    哨兵会将新主库的 IP 通知给其他从库,让其他从库再次执行以下 replicaof 命令设置主库。

    Redis 哨兵集群

    之前已经考虑过,从库挂掉、主库挂掉 Redis 会进行什么操作。 那么哨兵挂掉,又会发生什么事呢?

    实际上,通过上文也可以知道,哨兵不止一个,而是由一组哨兵组成了哨兵集群。所以,当某个哨兵挂掉了,其他哨兵还是一样能完成监控、选主、通知的操作的。

    在配置哨兵的时候,需要用到配置项:

    sentinel monitor <master-name> <ip> <redis-port> <quorum> 
    

    可以看到,这里只设置了主库的IP和端口,并没有配置其他哨兵和从库的连接信息。那么,哨兵之间是如何组成集群,又是怎么连接从库的呢?

    哨兵之间是如何发现的 —— pub/sub 机制
    哨兵之间能获取对方的 IP 和端口号,要依赖于 Redis 提供的 pub/sub 机制(发布/订阅机制)。 pub/sub 机制,就是在 Redis 注册了一个频道,发布就是向这个频道发送消息,订阅了这个频道的应用就能接收到这个消息,当然,只有订阅了这个频道,才能向这个频道发送消息。

    而在 Redis 的主库上,就有一个 "sentinel:hello" 频道,当设置一个新哨兵时,就会向这个频道发布消息。此时,其他已存在哨兵就会接收到这个新哨兵的IP和端口号,从而向这个新哨兵建立连接。

    哨兵是如何知道从库的IP和端口号的
    哨兵会向主库发送 INFO 命令,主库就会把从库列表返回给哨兵。

    主从库的切换,是由哪个哨兵完成的?
    我们已经知道了,新主库的选举规则,那么在哨兵集群中,是由哪个哨兵执行的主从库切换呢?

    实际上,由哪个哨兵执行,也是通过哨兵之间的选举完成的。

    当某个哨兵检测到主库 “主观下线”,会向其他哨兵发送 "is-master-down-by-addr" 命令。然后,其他哨兵会根据自己和主库的连接情况,返回 Y 或者 N 给这个哨兵。 当一个哨兵获取到了一定的 Y (配置为 quorum),也就是赞成票后,就能将主库标记为 “客观下线”。当哨兵实例拿到了过半的赞成票,并且超过了设定的 quorum,那么这个哨兵就能执行主从库切换。

    相关文章

      网友评论

          本文标题:五、Redis 的哨兵机制与哨兵集群

          本文链接:https://www.haomeiwen.com/subject/mlrbsltx.html