Redis（六）：哨兵（Sentinel ）

浅浅的花香味﹌ 2022-01-30 07:19 273阅读 0赞

### 文章目录 ###

*   *  1、Redis Sentinel 简介
     *   *  1.1、Redis Sentinel 是什么
         *  1.2、Redis Sentinel 解决什么问题
         *   *  1.2.1、主从复制问题
             *  1.2.2、Redis Sentinel 高可用
             *  1.2.3、主从复制与 Redis Sentinel 区别
             *  1.2.4、Redis Sentinel 高可用示例
     *  2、Redis Sentinel 实现原理
     *   *  2.1、定时任务
         *   *  2.1.1、每隔10秒
             *  2.1.2、每隔2秒
             *  2.1.3、每隔1秒
         *  2.2、主观下线和客观下线
         *   *  2.2.1、主观下线
             *  2.2.2、客观下线
         *  2.3、哨兵Leader选举
         *  2.4、故障转移

## 1、Redis Sentinel 简介 ##

### 1.1、Redis Sentinel 是什么 ###

Redis Sentinel 是 Redis 官方推荐的高可用（HA）解决方案，当Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身没有实现自动进行主备切换，那么服务将会挂掉，而Redis-sentinel本身是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能自动进行故障转移。

它的主要功能如下：

*  **监控：** Sentinel 会不断检查主实例（Master）和从属实例（Slave）是否正常工作。
 *  **通知：** 如果发现某个redis节点运行出现问题，它能够通知另外的节点或客户端
 *  **主节点自动故障转移：** 如果主服务器出现了问题，Sentinel 可以启动故障转移，从多个slave中选举出一个作为新master，并告知其它slave变更主master地址。
 *  **配置提供者：** Sentinel 充当客户端服务发现：客户端连接到Sentinels，获取主master的地址， 如果发生故障转移，Sentinels 将会告知客户端master的新地址

### 1.2、Redis Sentinel 解决什么问题 ###

#### 1.2.1、主从复制问题 ####

Redis 的主从复制模式可以将主节点的数据及改变同步到从节点，这样从节点就有两个作用：

1）作为主节点的一个备份，当主节点出现故障时，保证了数据的最大完整性

2）从节点可以扩展主节点的读能力，面对大并发的读操作，从节点在一定程度上可以分担主节点的读压力。

**主从复制也存在以下问题：**

1）当主节点出现故障，需要人为干预切换一个从节点为主节点，同时又要修改应用端的主节点地址

2）主节点的写能力受到单机的限制

3）主节点的存储能力受到单机的限制

#### 1.2.2、Redis Sentinel 高可用 ####

当主节点出现故障时，Redis Sentinel 能自动完成故障发现和故障转移，并通知应用放，从而实现真正的高可用。

#### 1.2.3、主从复制与 Redis Sentinel 区别 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA2NDcwMzU_size_16_color_FFFFFF_t_70]

#### 1.2.4、Redis Sentinel 高可用示例 ####

下面我们先从一个简单示例了解一下 sentinel 集群模式。这是一个一主两从，三个哨兵节点组成的redis集群，我们看到这里的 sentinel 是整个集群的核心，它一般是由 3～5 个节点组成，个别节点挂了集群还可以正常运转。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA2NDcwMzU_size_16_color_FFFFFF_t_70 1]

sentinel 负责持续监控主从节点的健康，当主节点挂掉时，自动选举一个从节点切换为主节点。当客户端连接集群时，会首先连接 sentinel，通过 sentinel 来获取主节点的地址，然后再去连接主节点进行数据交互。当主节点发生故障时，客户端会重新向 sentinel 获取地址，sentinel 会将最新的主节点地址告诉客户端。这样的情况下，应用程序将无需重启即可自动完成节点切换。

假如上图的主节点挂掉了，集群将自动调整为下图所示：

从这张图中我们能看到主节点挂掉了，原先的主从复制也断开了，客户端和损坏的主节点也断开了。从节点被提升为新的主节点，其它从节点开始和新的主节点建立复制关系。客户端通过新的主节点继续进行交互。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA2NDcwMzU_size_16_color_FFFFFF_t_70 2]

Sentinel 会持续监控已经挂掉了主节点，等它恢复后，集群会自动调整为下图所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA2NDcwMzU_size_16_color_FFFFFF_t_70 3]

## 2、Redis Sentinel 实现原理 ##

### 2.1、定时任务 ###

每个哨兵（Sentinel）节点维护了 3 个定时任务来实现对各个节点发现和监控

#### 2.1.1、每隔10秒 ####

每隔10秒，每个Sentinel 节点会向主从节点（master 和 slave）发送 info 命令获取最新的拓扑结构  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA2NDcwMzU_size_16_color_FFFFFF_t_70 4]

该定时任务的作用主要表现再以下三个方面：

*  通过向主节点执行info命令，获取从节点信息，这也是sentinel节点不需要显式配置从节点的原因
 *  可以及时感知新的从节点加入
 *  节点不可达或故障转移后，可以通过info命令实时更新节点拓扑结构

#### 2.1.2、每隔2秒 ####

每隔2秒，每个Sentinel节点会向Redis数据节点的 **sentinel**:hello 频道上发送Sentinel节点对于主节点的判断以及当前Sentinel节点的信息，同时每个Sentinel节点也会订阅该频道，来获取其他Sentinel节点信息以及对主节点的判断信息。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA2NDcwMzU_size_16_color_FFFFFF_t_70 5]

该定时任务的作用主要表现再以下两个方面：

*  发现新的sentinel节点，通过订阅主节点的 **sentinel**:hello 来获取其他sentinel节点信息，如果有新加入的sentinel节点，获取新节点信息并与其创建连接。
 *  sentinel节点之间交换主节点信息，作为客观下线及leader选举的依据

#### 2.1.3、每隔1秒 ####

每隔1秒，每个Sentinel节点会向主节点、从节点、其余Sentinel节点发送一条ping命令做一次心跳检测，来确认这些节点当前是否可达

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA2NDcwMzU_size_16_color_FFFFFF_t_70 6]

### 2.2、主观下线和客观下线 ###

#### 2.2.1、主观下线 ####

每隔Sentinel节点每隔1秒就会对主节点、从节点、其他sentinel节点发送ping命令做心跳检查，当某个节点超过 down-after-millisseconds 没有有效回复时，Sentinel节点就会认为该节点不可达，这个行为就叫 主观下线。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA2NDcwMzU_size_16_color_FFFFFF_t_70 7]

#### 2.2.2、客观下线 ####

当Sentinel主观下线的节点是主节点时，该Sentinel节点会通过 sentinel is-master-down-by-addr 命令向其他Sentinel节点询问对主节点的判断，当超过 个Sentinel节点认为主节点有问题时，那么Sentinel就判定为该主节点是客观下线。

quorum 个数取决于 sentinel.conf 中的配置：

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA2NDcwMzU_size_16_color_FFFFFF_t_70 8]

### 2.3、哨兵Leader选举 ###

当某个主节点已经被sentinel判定为客观下线后，接下来会由sentinel来进行故障转移工作了，但并不是随便一个sentinel就可以胜任的。所以Sentinel节点之间会做一个leader选举，选出一个leader来进行故障转移工作。

Redis 使用了Raft算法来实现leader选举的，Redis Sentinel 进行领导选举的大致逻辑如下：

1、每个在线的Sentinel节点都有资格成为leader，当它判定主节点主观下线时，会向其它Sentinel节点发送sentinel is-master-down-by-addr命令，请求将自己设置为leader。

2、收到命令的Sentinel节点，如果还没同意过其他Sentinel节点的请求，那么该节点将同意，否则拒绝。

3、如果该Sentinel节点发现自己的认可数量大于等于 max(quorum,num(sentinels)/2+1) ,那么它将成为leader。

4、如果经过以上过程没有选举出leader，那么将进入下一轮选举。

### 2.4、故障转移 ###

哨兵Leader选举完成后，将由该 Sentinel Leader 来完成故障转移工作，那么怎么在所有从节点中选出合适的主节点呢？

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA2NDcwMzU_size_16_color_FFFFFF_t_70 9]

大致步骤如下：

1）过滤掉不健康的节点，满足以下任意一个条件的节点都被认为不健康

*  被判定为主观下线的节点
 *  5秒内没有回复过sentinel节点ping请求的节点
 *  与主节点失联超过 down-after-milliseconds 设置的时间的节点

2）选择 replica-priority（从节点优先级）最高的节点，如果存在则返回，否则继续

3）选择复制偏移量最大的从节点（数据最完整），如果存在则返回，否则继续

4）执行至此，会默认选择 runid 最小的从节点

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA2NDcwMzU_size_16_color_FFFFFF_t_70]: /images/20220130/b2bf9a829e54481a943d5d32c473f55d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA2NDcwMzU_size_16_color_FFFFFF_t_70 1]: /images/20220130/055fe8a3923d45079372d1bba2fdaf2f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA2NDcwMzU_size_16_color_FFFFFF_t_70 2]: /images/20220130/147e89d2f6214d6386e97c7b902c2125.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA2NDcwMzU_size_16_color_FFFFFF_t_70 3]: /images/20220130/bface059fcf540aeb9904e08596ffe2d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA2NDcwMzU_size_16_color_FFFFFF_t_70 4]: /images/20220130/0d867b6aeba14964a2872a31c96eb581.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA2NDcwMzU_size_16_color_FFFFFF_t_70 5]: /images/20220130/5600683804cf43cc8ce3e9535d48ba2b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA2NDcwMzU_size_16_color_FFFFFF_t_70 6]: /images/20220130/dcb7d514054043cfa3245d332e56d259.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA2NDcwMzU_size_16_color_FFFFFF_t_70 7]: /images/20220130/e1b013e6b94647ac93c1636b1e4faea9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA2NDcwMzU_size_16_color_FFFFFF_t_70 8]: /images/20220130/821d55ac806147559bf8afb0655bbbb6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA2NDcwMzU_size_16_color_FFFFFF_t_70 9]: /images/20220130/0ab39d60ffa143b88fa50dfdfe6583ea.png