超全面 Redis 分布式高可用方案：哨兵机制

开发工作中对于分布式缓存高可用方案（搭建 Redis 缓存高可用方案），Redis 主从架构下是如何保证高可用的呢？

我们知道 Redis Sentinel 是一个分布式系统，为 Redis 提供高可用性解决方案。那 Redis 服务部署的哨兵模式主要原理是什么，又解决了什么问题呢，于是利用时间将相关问题做了整理，相信看完这篇文章，你也可以去给别人做技术分享了。O(∩_∩)O 哈哈~

0. 问题铺垫

在讨论哨兵模式之前，我们先来看一个应用问题：Redis 服务主机宕机。

实际使用过程中，会出现 master 宕机的情况（这样会导致没有写服务，只有读服务）。那我们要保证服务的可用，就需要从其他 salve 节点中选取一个来作为 master 节点，来继续提供服务能力。

那主要的动作抽象下：

• 将宕机的 master 下线

• 找一个 slave 作为 master

• 通知所有的 slave 连接新的 master

• 全量数据或者部分数据同步

其中存在几个问题：

• 谁来确认 master 宕机？（假如仅仅是网络抖动了一下，就把我宕掉么？）

• 如何从 slave 中找一个 master 代替，谁来找？怎么找？有什么依据？

• 修改配置后，原始的主恢复了怎么办？

其实引入了哨兵机制，就可以很好的解决上述问题。

1. 什么是哨兵？

Sentinel（哨兵）是 Redis 的高可用性解决方案，由一个或多个 Sentinel 实例组成的 Sentinel 系统可以监视任意多个主服务，以及这些主服务器属下的所有从服务，并在被监视的主服务进入下线（不可服务）状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器。

总结一下哨兵的作用：

• 集群监控

不断的检查 master 和 slave 是否正常运行（master 存活检测、master 与 slave 运行情况检测）

• 消息通知

当被监控的服务器出现问题时，向其他哨兵、客户端发送通知

• 自动故障转移

断开故障 master 与 slave 的连接，选取一个 slave 作为新 master，将其他 slave 连接到新的 master 并告知客户端新的服务器地址。

注意：哨兵也是一台 Redis 服务器，只是不提供数据服务；通常哨兵配置的数量为单数。

2. 哨兵的工作原理

下面主要针对哨兵在进行主从切换过程中经历的三个阶段分别进行阐述。

2.1. 集群监控

step1：哨兵 1 连接到 Redis 集群

• 发送 info 命令到 master，并建立 cmd 连接；

• 哨兵端保存哨兵状态（SentinelStatus），保存所有哨兵状态，主节点和从节点的信息；master 端会记录 redis 实例的信息（SentinelRedisInstance）；

• 哨兵根据 master 中获取的每个 slave 信息，去连接每个 slave，发送同样也是 info 命令。

step2：哨兵 2 加入进来后

• 同样会发送 info 命令到 master 节点，并建立 cmd 连接；

• 发现 master 中存在其他哨兵节点的信息，哨兵 2 中保存哨兵信息（区别与哨兵 1 的是它保存了哨兵 1 和哨兵 2 的 2 个哨兵节点信息）；

• 为了每个哨兵的信息都一致它们之间建立了一个发布订阅。为了哨兵之间的信息长期对称它们之间也会互发 ping 命令。

step3：哨兵 3 加入后

• 同样进行哨兵 1、2 的动作，会发送 info 命令到 master 节点，并建立 cmd 连接；

• 为了保证哨兵 1-哨兵 2 之间的信息是同步的，建立了一个发布订阅的一个队列（可以互发 ping 命令）

小小总结一下：

• Sentinel 会向 master、slave 以及其他 Sentinel 获取状态

• Sentinel 之间会组建“对应频道”，大家一起发布信息、订阅信息、收信息、同步信息等。

2.2. 消息通知

1）Sentinel 节点会通过 master/slave 节点建立的 cmd 连接获取其工作状态

2）Sentinel 收到反馈结果之后，会在哨兵内部进行信息的互通

3、故障转移

关于故障转移，严格来讲可划分两个步骤：故障判定、故障转移。

Q1：如何判断一个节点出现故障？

• 哨兵会一直给主节点发送 publish sentinel：hello

直到主节点故障，哨兵报出 sdown，同时此哨兵还会向其他哨兵发布消息说这个主节点挂了。发送的指令是 sentinel is-master-down-by-address-port。

• 其余的哨兵接收到指令后，主节点挂了吗？让我去看看到底挂没挂。发送的信息也是 hello。

其余的哨兵也会发送他们收到的信息并且发送指令 sentinel is-master-down-by-address-port 到自己的内网，确认一下第一个发送 sentinel is-master-down-by-address-port 的哨兵说你说的对，这个家伙确实挂了。

• 当所有人都认为主节点挂了后就会修改其状态为 odown。

当一个哨兵认为主节点挂了标记的是 sdown，当半数哨兵都认为挂了其标记的状态是 odown。

一个哨兵认为 master 节点挂了称为主观下线（sdown），超半数哨兵认为 master 节点挂了则称为客观下线（odown）。

Q2：如何进行故障转移？

1）首先，哨兵选举出哨兵 Leader 去处理故障转移

此时选举方式应用的是 Raft 协议，Raft 是一种实现分布式共识的协议。所谓共识，就是多个节点对某个事情达成一致的看法，即使是在部分节点故障、网络延时、网络分割的情况下。

这个之前有过介绍，感兴趣的同学可以移步了解：一致性算法 Raft 简述

2）其次，哨兵 Leader 从所有的 slave 节点找出一个作为 master 节点

主要的规则：

• 选择在线的节点，pass 掉已下线的节点；

• 选择响应速度快的，pass 掉响应慢的节点

• 选择与原 master 断开时间短的，pass 掉断开时间较长的；

假如以上优先级均一致，会考虑其他优先原则：

• 偏移量较大

假如说 slave1 的 offset 为 50，slave2 偏移量为 55，则哨兵就会选择 slave2 为新的主节点。

• runid 偏大的

这点类似于职场中的论资排辈，也就说根据 runid 的创建时间来判断，时间早的先上位。

3）数据转移

• 新 master 上任：Sentinel 向新的 master 发送 slaveof no one

• 其他 slave 周知：向其他 slave 发送 slaveof 新 master IP 端口

3. 总结

Redis 主从复制的作用中有这么一句话“主从复制是高可用的基石”，那实现高可用必不可少的就是哨兵和集群。

3.1. Sentinel 的作用

• 集群监控

不断的检查 master 和 slave 是否正常运行（master 存活检测、master 与 slave 运行情况检测）

• 消息通知

当被监控的服务器出现问题时，向其他哨兵、客户端发送通知

• 自动故障转移

断开故障 master 与 slave 的连接，选取一个 slave 作为新 master，将其他 slave 连接到新的 master 并告知客户端新的服务器地址。

3.2. Sentinel 的工作方式

• 每个 Sentinel 以每秒钟一次的频率向它所知的 Master，Slave 以及其他 Sentinel 实例发送一个 PING 命令

• 如果一个实例（Instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。

若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。

• 如果一个 Master 被标记为主观下线，则正在监视这个 Master 的所有 Sentinel 要以每秒一次的频率确认 Master 的确进入了主观下线状态。

• 当有足够数量的 Sentinel（>=配置文件指定的值）在指定的时间范围内确认 Master 的确进入了主观下线状态， 则 Master 会被标记为客观下线

若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。

• 在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有 Master，Slave 发送 INFO 命令

• 当 Master 被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次

希望今天的讲解对大家有所帮助，Thanks for reading!