Redis - Sentinel（哨兵）

比眉伴天荒 2022-12-22 14:27 176阅读 0赞

### 文章目录 ###

*  1. 初始化Sentinel
 *   *  1.1 初始化服务器
     *  1.2 使用Sentinel专用代码
     *  1.3 初始化Sentinel状态
     *  1.4 初始化Sentinel状态的masters属性
     *  1.5 创建连向主服务器的网络连接
 *  2. Sentinel获取信息
 *  3. 检测下线
 *   *  leader选举规则
 *  4. 故障转移
 *   *  主服务器挑选过程
 *  5. 相关问题
 *   *   *  1）主从切换完成之后，客户端和其他哨兵如何知道现在提供服务的Redis Master是哪一个呢？
         *  2）执行切换的哨兵发生了故障，切换操作是否会由其他哨兵继续完成呢？
         *  3）故障Master恢复之后，会继续作为Master提供服务还是会作为Slave提供服务？

> Sentinel只是一个运行在特殊模式下的Redis服务器。  
> Sentinel（哨岗、哨兵）是Redis的高可用性（high availability）解决方案：由一个或多个Sentinel实例（instance）组成的Sentinel系统（system）可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。

一个典型的sentinel部署方案：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70_pic_center]

# 1. 初始化Sentinel #

redis-sentinel sentinel.conf
    redis-server sentinel.conf --sentinel

当一个Sentinel启动时，它需要执行以下步骤：  
1）初始化服务器。  
2）将普通Redis服务器使用的代码替换成Sentinel专用代码。  
3）初始化Sentinel状态。  
4）根据给定的配置文件，初始化Sentinel的监视主服务器列表。  
5）创建连向主服务器的网络连接。

## 1.1 初始化服务器 ##

Sentinel本质上只是一个运行在特殊模式下的Redis服务器，所以启动Sentinel的第一步，就是初始化一个普通的Redis服务器。

> 无需载入RDB或者AOF

## 1.2 使用Sentinel专用代码 ##

将一部分普通Redis服务器使用的代码替换成Sentinel专用代码，修改端口，启用Sentinel对应命令。

## 1.3 初始化Sentinel状态 ##

服务器会初始化一个sentinel.c/sentinelState结构，这个结构保存了服务器中所有和Sentinel功能有关的状态。

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

## 1.4 初始化Sentinel状态的masters属性 ##

Sentinel状态中的masters字典记录了所有被Sentinel监视的主服务器的相关信息，其中：

*  字典的键是被监视主服务器的名字。
 *  而字典的值则是被监视主服务器对应的sentinel.c/sentinelRedisInstance结构。

每个sentinelRedisInstance结构代表一个被Sentinel监视的Redis服务器实例（instance），这个实例可以是主服务器、从服务器，或者另外一个Sentinel。

## 1.5 创建连向主服务器的网络连接 ##

> 哨兵的配置文件必须具有可写权限。

创建连向被监视主服务器的网络连接，Sentinel将成为主服务器的客户端，它可以向主服务器发送命令，并从命令回复中获取相关的信息。

对于每个被Sentinel监视的主服务器来说，Sentinel会创建两个连向主服务器的异步网络连接：

*  命令连接，这个连接专门用于向主服务器发送命令，并接收命令回复。
 *  订阅连接，这个连接专门用于订阅主服务器的\_\_sentinel\_\_:hello频道。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70_pic_center 2]  
哨兵就是通过如上两条连接发现其他哨兵和Redis Slave服务器，并且与每个Redis Slave也建立同样的两条连接。具体流程我们通过哨兵的启动过程详细阐述。

> **为什么有两个连接？**  
> 在Redis目前的发布与订阅功能中，被发送的信息都不会保存在Redis服务器里面，如果在信息发送时，想要接收信息的客户端不在线或者断线，那么这个客户端就会丢失这条信息。因此，为了不丢失\_\_sentinel\_\_:hello频道的任何信息，Sentinel必须专门用一个订阅连接来接收该频道的信息。另一方面，除了订阅频道之外，Sentinel还必须向主服务器发送命令，以此来与主服务器进行通信，所以Sentinel还必须向主服务器创建命令连接。因为Sentinel需要与多个实例创建多个网络连接，所以Sentinel使用的是异步连接。

# 2. Sentinel获取信息 #

Sentinel默认会以每十秒一次的频率，通过命令连接向被监视的主服务器发送INFO命令，并通过分析INFO命令的回复来获取主服务器的当前信息。主要包括：run\_id域记录的服务器运行ID，以及role域记录的服务器角色，主服务器属下所有从服务器的信息。

根据run\_id域和role域记录的信息，Sentinel将对主服务器的实例结构进行更新。

当Sentinel发现主服务器有新的从服务器出现时，Sentinel除了会为这个新的从服务器创建相应的实例结构之外，Sentinel还会创建连接到从服务器的命令连接和订阅连接。

当Sentinel与一个主服务器或者从服务器建立起订阅连接之后，Sentinel就会通过订阅连接，Sentinel对\_\_sentinel\_\_:hello频道的订阅会一直持续到Sentinel与服务器的连接断开为止。这个频道是一个双向的通道。

但是请注意，一个Sentinel发送的信息会被其他Sentinel接收到。其实现是通过订阅这个\_\_sentinel\_\_:hello实现的。

其次，当Sentinel通过频道信息发现一个新的Sentinel时，它不仅会为新Sentinel在sentinels字典中创建相应的实例结构，还会创建一个连向新Sentinel的命令连接。

# 3. 检测下线 #

在默认情况下，Sentinel会以每秒一次的频率向所有与它创建了命令连接的实例（包括主服务器、从服务器、其他Sentinel在内）发送PING命令，并通过实例返回的PING命令回复来判断实例是否在线。

如果某个哨兵认为其监听的Master处于下线的状态，这个状态在Redis中标记为S\_DOWN，即**主观下线**。假设quorum配置为2，则当有两个哨兵同时认为一个Master处于下线的状态时，会标记该Master为O\_DOWN，即**客观下线**。只有一个Master处于客观下线状态时才会开始执行切换。

--------------------

当一个主服务器被判断为客观下线时，监视这个下线主服务器的各个Sentinel会进行协商，选举出一个领头Sentinel，并由领头Sentinel对下线主服务器执行故障转移操作。

## leader选举规则 ##

> Sentinel系统选举领头Sentinel的方法是对Raft算法的领头选举方法的实现

*  所有在线的Sentinel都有被选为领头Sentinel的资格。
 *  每次进行领头Sentinel选举之后，不论选举是否成功，所有Sentinel的配置纪元（configuration epoch）的值都会自增一次。
 *  在一个配置纪元里面，所有Sentinel都有一次将某个Sentinel设置为局部领头Sentinel的机会，并且局部领头一旦设置，在这个配置纪元里面就不能再更改。
 *  **每个发现主服务器进入客观下线的Sentinel都会要求其他Sentinel将自己设置为局部领头Sentinel。**
 *  **Sentinel设置局部领头Sentinel的规则是先到先得**：最先向目标Sentinel发送设置要求的源Sentinel将成为目标Sentinel的局部领头Sentinel，而之后接收到的所有设置要求都会被目标Sentinel拒绝。
 *  如果有某个Sentinel被半数以上的Sentinel设置成了局部领头Sentinel，那么这个Sentinel成为领头Sentinel。
 *  一个配置纪元里面，只会出现一个领头Sentinel。

# 4. 故障转移 #

领头Sentinel将对已下线的主服务器执行故障转移操作：

1）在已下线主服务器属下的所有从服务器里面，挑选出一个从服务器，并将其转换为主服务器。

2）让已下线主服务器属下的所有从服务器改为复制新的主服务器。

3）将已下线主服务器设置为新的主服务器的从服务器，当这个旧的主服务器重新上线时，它就会成为新的主服务器的从服务器。

## 主服务器挑选过程 ##

领头Sentinel会将已下线主服务器的所有从服务器保存到一个列表里面，然后按照以下规则，一项一项地对列表进行过滤：

1）如果该Slave处于主观下线状态，则不能被选中。  
2）如果该Slave 5s之内没有有效回复ping命令或者与主服务器断开时间过长，则不能被选中。  
3）如果slave-priority为0，则不能被选中（slave-priority可以在配置文件中指定。正整数，值越小优先级越高，当指定为0时，不能被选为主服务器）。4）在剩余Slave中比较优先级，优先级高的被选中；如果优先级相同，则有较大复制偏移量的被选中；否则按字母序选择排名靠前的Slave。

之后向选出来的salve发送SLAVEOF no one 命令使其成为主服务器。接着领头Sentinel会以每秒一次的频率（平时是每十秒一次），向被升级的从服务器发送INFO命令，并观察命令回复中的角色（role）信息，当被升级服务器的role从原来的slave变为master时，领头Sentinel就知道被选中的从服务器已经顺利升级为主服务器了。

--------------------

领头Sentinel下一步要做的就是，让已下线主服务器属下的所有从服务器去复制新的主服务器，这一动作可以通过向从服务器发送SLAVEOF命令来实现。

# 5. 相关问题 #

### 1）主从切换完成之后，客户端和其他哨兵如何知道现在提供服务的Redis Master是哪一个呢？ ###

答：可以通过subscribe **sentinel**:hello频道，知道当前提供服务的Master的IP和Port。

### 2）执行切换的哨兵发生了故障，切换操作是否会由其他哨兵继续完成呢？ ###

答：执行切换的哨兵发生故障后，剩余哨兵会重新选主，并且重新开始执行切换流程。

### 3）故障Master恢复之后，会继续作为Master提供服务还是会作为Slave提供服务？ ###

答：Redis中主从切换完成之后，当故障Master恢复之后，会作为新Master的一个Slave来提供服务。

--------------------

读书笔记 - 《Redis设计与实现》

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70_pic_center]: /images/20221120/317a9baae08f43d2b386d95637a87129.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70_pic_center 1]: https://img-blog.csdnimg.cn/20201120171006560.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc=,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70_pic_center 2]: https://img-blog.csdnimg.cn/20201120222129358.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc=,size_16,color_FFFFFF,t_70#pic_center