Redis系列4：高可用之Sentinal(哨兵模式）

1 背景

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

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

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

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

2 什么是哨兵模式

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

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。

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

这里的 一定数量 是一个法定数量（Quorum），是由哨兵监控配置决定的，配置的结构如下：​

# sentinel monitor <master-name> <master-host> <master-port> <quorum>
# 举例如下：
sentinel monitor master_01 127.0.0.1 8888 3

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

• sentinel monitor：代表监控。
• master_01：代表主节点的名称，根据你实际的主节点定义。
• 127.0.0.1：代表监控的主节点 ip，8888 代表端口。
• 3：法定数量，代表只有两个或两个以上的哨兵认为主节点不可用的时候，才会把 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。

3.3 信息通知

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

4 关于哨兵集群

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

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

使用redis的pub/sub 订阅能力实现哨兵间通信 和 slave 发现。哨兵之间可以相互通信，主要归功于 Redis 的 pub/sub 发布/订阅机制。哨兵与 master 建立通信之后，可以利用 master 提供发布/订阅机制发布自己的IP、port等信息master 有一个 sentinel:hello 的专用通道，用于哨兵之间发布和订阅消息。哨兵们都可以通过该通道发布自己的消息，同时订阅其他哨兵发布的消息。

4.2 哨兵如何与slave实现连接

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

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

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

5 总结

5.1 哨兵主要任务

Redis中的哨兵机制是实现 Redis 服务高可用重要模式之一。为主从集群之间的数据同步，提供高可靠的基础保障。也能在主库实例发生宕机时，提供监控、竞选和自动切换主从的能力。主从切换过程如下：

• 监控 master 与 slave 的健康状态，判断是否客观下线。
• master 客观下线后，竞选一个 slave ，并切换成 master。
• 将新 master 的信息下发到 slaves 和 clients。

5.2 哨兵集群原理

哨兵也可能产生故障，为避免单个哨兵故障后无法执行主从切换，并降低误判率，我们使用了哨兵集群。哨兵集群的运行机制如下：

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

后续的主从切换工作，是通过投票竞选一个哨兵 Leader来进行的，并不是随意一个哨兵可以操作的，所以这也体现一定的严谨性。

文章转载自公众号：  架构与思维