Redis系列4:高可用之Sentinel(哨兵模式)

Redis系列1:深刻理解高性能Redis的本质
Redis系列2:数据持久化提高可用性
Redis系列3:高可用之主从架构

1 背景

从第三篇 Redis系列3:高可用之主从架构 ,我们知道,为Redis配置主从模式,可以大幅度的提高Redis服务的可用性,减少甚至避免Redis服务发生宕机的可能。
它有如下能力:

  • 故障隔离和恢复:无论主节点或者从节点宕机,其他节点依然可以保证服务的正常运行,并可以手动切换主从。
  • 读写隔离:Master 节点提供写服务,Slave 节点提供读服务,分摊流量压力,均衡流量的负载。
  • 提供高可用保障:主从模式是高可用的最基础版本,也是哨兵模式和 cluster模式实施的前置条件。

但是依然存在不小的问题,我们知道,在衡量系统可用性这边有个指标叫做MTTR,即平均修复时间。虽然主从模式支持手动切换,但是我们从知道服务故障到手动切换止损到恢复,这可能是一个比较长的过程。这期间的损失将难以计量,对于超高并发大系统是一个绝对灾难。所以我们需要系统自动的感知到Master故障,并选择一个 Slave 切换为 Master,实现故障自动转移的能力。

平均修复时间(Mean time to repair,MTTR),是描述产品由故障状态转为工作状态时修理时间的平均值。

2 什么是哨兵模式

在实际生产环境中,服务器难免会遇到一些突发状况:服务器宕机,停电,硬件损坏等等,一旦发生,后果不堪设想。
哨兵模式的核心还是主从模式的演变,只不过相对于主从模式在主节点宕机导致不可写的情况下,多了探活,以及竞选机制:从所有的从节点竞选出新的主节点,然后自动切换。竞选机制的实现,是依赖于在系统中启动sentinel进程,对各个服务器进行监控。如下图所示:
image

3 哨兵模式的主要职责

我们知道,要让Redis服务实现故障自动切换会有很多细节需要考虑,比如:

  • 判定节点故障的条件是什么,有没有可能是假死或者响应延迟。
  • 既然是竞选机制,那么所有slave节点都可以参与竞争,也都有机会成为master。选择哪个slave成为master是关键。
  • 竞选出新的master,其他slave需要从新的master中replicaof,所以消息通知和通信也是核心。

带着这些思考,我们来看看官方对Redis哨兵的定义:
哨兵作为 Redis 的一种运行模式,专注于对 Redis 实例(master、slaves)运行状态进行监控,并能够在主节点发生故障时通过一系列的操作,实现新的master竞选、主从切换、故障转移,确保整个 Redis 服务的可用性。
所以,哨兵的能力至少应该包含如下几点:

  • 监控:持续监控 master 、slave 是否健康,是否处于预期工作状态。
  • 主从动态切换:当 Master 运行故障,哨兵启动自动故障恢复流程:从 slave 中选择一台作为新 master。
  • 通知机制:竞选出新的master之后,通知客户端与新 master 建立连接;slave 从新的 master 中 replicaof,保障主从数据的一致性。

接下来我们一个个来看这几个能力的实现过程。

3.1 监控能力

哨兵模式启用的时候,会同步启用叫做Sentinel的进程。sentinel程会向所有的master 和 slaves 以及其他sentinel进程 发送心跳包(1s一次),看看是否正常返回响应。

  • 如果slave 没有在规定的时间内响应 sentinel 的 PING 命令 , sentinel 会认为该实例已经挂了,将它tag为:下线状态;
  • 同理,如果master 没有在规定时间响应 sentinel 的 PING 命令,也会被判定为 offline 状态,只是会多做一步 自动切换 master 的流程。

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

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

但是可能存在一些误判的情况,比如说网络拥塞、master实例假死、请求延迟,导致实例在某个短暂时间段不可用,后续又快速恢复了。
如果这时候被我们主动下线了,其实整个系统的可用性反而遭到了退化。而且 误判之后的一系列操作,master竞选、消息通知,slave 与新 master 同步数据,都会消耗大量资源。所以,误判要不得啊。
为了保证判断的可靠性,我们对下线的标识做了区分:一种是 主观下线,一种是客观下线。

  • 主观下线
    哨兵利用 PING 命令来监测 master、 slave 实例节点的生命状态。如果是无效回复,哨兵就把这个实例节点标记为 主观下线 。如果是slave,一般是有多从概念,直接下线即可,但如果是master,就要小心了。一个人sentinel容易误判,那就多个sentinel进投票裁决。哨兵机制就是这样的,采用多个实例组成sentinel集群模式进行部署,即哨兵集群。多个哨兵实例一起来判断,就可以避免单个哨兵因为自身网络状况不好,而误判主库下线的情况。
    同时,多个哨兵的网络同时不稳定的概率较小,由它们一起做决策,误判率也能降低。

  • 客观下线
    master 是否要下线不能是单个sentinel能够决定的,上面说了我们一帮会有个sentinel集群 ,所以这个集群就发挥作用了,大家一起投票,超过一半的sentinel 都判断了 主观下线 ,这时候我们就把 master 标记为 客观下线,认为它是真的不行了。
    当 master 被判定为 客观下线 后,就算正式没有master了,当务之急就是赶紧竞选出一个新的master。
    image

  • 如何区别主、客观下线
    主观下线是sentinel自己认为节点offline,这时候节点并不是真正的下线;而客观下线是达到一定数量的哨兵(比如超过一半)都认为节点offline了,这时候会进一步触发离线、重新竞选主等一系列操作。

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

# sentinel monitor <master-name> <master-host> <master-port> <quorum>
# 举例如下:
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 为 客观下线 ,其实就是过半机制。

3.2 主从动态切换

sentinel 的一个很重要工作,就是从多个slave中选举出一个新的master。当然,这个选举的过程会比较严谨,需要通过 筛选 + 综合评估 方式进行选举,

3.2.1 筛选

  • 过滤掉不健康的(下线或者断线),没有回复哨兵ping响应的从节点。
  • 评估实例过往的网络连接状况 down-after-milliseconds,如果一定周期内(如24h)从库和主库经常断连,而且超出了一定的阈值(如 10 次),则该slave不予考虑。
    这样,就保留下比较健康的实例了。

3.2.2 综合评估

筛选掉不健康的实例之后,我们就可以对于剩下健康的实例按顺序进行综合评估了。

  • slave 优先级,通过 slave-priority 配置项(redis.conf),可以给不同的从库设置不同优先级,优先级高的优先成为master。
  • 选择数据偏移量差距最小的,即slave_repl_offset与 master_repl_offset进度差距,其实就是比较 slave 与 原master 复制进度差距。
  • slave runID,在优先级和复制进度都相同的情况下,选用runID最好的,runID越小说明创建时间越早,优先选为master。先来后到原则。

等这几个条件都评估完,我们就会选择出最适合slave,把他推举为新的master。
image

3.3 信息通知

等推选出最新的master之后,后续所有的写操作都会进入这个master中。所以需要尽快通知到所有的slave,让他们重新 replacaof 到 master上,重新建立runID和slave_repl_offset ,来保证数据的正常传输和主从一致性。如下图所示:
image

4 关于哨兵集群

前面说过了,单个哨兵对redis实例的离线判断可能会有误判,所以会有一个sentinel集群的概念,超过一定比例的sentinel(比如 > 1/2)的判断为主观下线,才能形成实质的客观下线。
那这边有几个知识点我们需要梳理清楚。

4.1 集群中的哨兵如何实现通信

使用redis的pub/sub 订阅能力实现哨兵间通信 和 slave 发现。
哨兵之间可以相互通信,主要归功于 Redis 的 pub/sub 发布/订阅机制。哨兵与 master 建立通信之后,可以利用 master 提供发布/订阅机制发布自己的IP、port等信息
master 有一个 sentinel:hello 的专用通道,用于哨兵之间发布和订阅消息。哨兵们都可以通过该通道发布自己的Name、IP、Port消息,同时订阅其他哨兵发布的Name、IP、Port消息。互相发现之后建立起了连接,后续的消息通信就可以直接进行了。
★这个与微服务中的服务注册与发现,以及RPC通信类似的整套做法类似。
image

4.2 哨兵如何与slave实现连接

  • sentinel向master发送 INFO 命令
  • master返回与之关联的slave 列表
  • sentinel 根据 master 返回的 slave 列表,逐个与 salve 建立连接,并且根据这个连接持续监控
    image

4.3 哨兵如何与客户端进行事件通知

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

5 总结

5.1 哨兵主要任务

Redis 哨兵机制是实现 Redis 不间断服务的高可用手段之一。主从架构集群的数据同步,是数据可靠的基础保障;主库宕机,自动执行主从切换是服务不间断的关键支撑。
Redis 哨兵机制实现了主从库的自动切换,再也不怕跟女盆友么么哒的时候 master 宕机了:

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

5.2 哨兵集群原理

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

  • 基于 pub/sub 机制实现哨兵集群之间的通信;
  • 基于 INFO 命令获取 slave 列表,帮助 哨兵与 slave 建立连接;
  • 通过哨兵的 pub/sub,实现了与客户端和哨兵之间的事件通知。
    主从切换,并不是随意选择一个哨兵就可以执行,而是通过投票仲裁,选择一个 Leader,由这个 Leader 负责主从切换。

//mp.weixin.qq.com/s?__biz=MzkzMDI1NjcyOQ==&mid=2247487780&idx=1&sn=9a0ea0971e661556c4c5e438ab1b081b&chksm=c27c5312f50bda04231254e78736d151f789ef056f43d36f7cd861c70f0cb54b7e26ea03d5d4&scene=178&cur_album_id=1918295695426404359#rd