Redis分布式集群实战（三）——搭建Redis哨兵（Sentinel）模式[高可用]

一时失言乱红尘 2023-07-18 02:49 11阅读 0赞

### 文章目录 ###

*  一、哨兵模式
 *   *  1、定义
     *  2、功能作用
     *  3、原理
     *  4、工作方式
     *  5、配置文件
 *  二、搭建Redis哨兵模式
 *   *   *   *  解读6379.conf 文件中部分参数信息
 *  三、故障转移的具体步骤：

# 一、哨兵模式 #

主从切换技术的方法是：**当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。** 哨兵模式就是为了解决此类问题而产生的。

## 1、定义 ##

**Sentinel(哨兵)是用于监控redis集群中Master状态的工具，是Redis 的高可用性解决方案，** sentinel哨兵模式已经被集成在redis2.4之后的版本中。sentinel系统可以监视一个或者多个redis master服务，以及这些master服务的所有slave；**当某个master服务下线时，自动将该master下的slave升级为master服务替代已下线的master服务继续处理请求。**

sentinel可以让redis实现主从复制，当一个集群中的master失效之后，sentinel可以选举出一个新的master用于自动接替master的工作，集群中的其他redis服务器自动指向新的master同步数据。一般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致误切换。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70]

## 2、功能作用 ##

**监控(monitoring)**：Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。  
**提醒(Notifation)**：当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。  
**自动故障转移(Automatic failover)**：当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

## 3、原理 ##

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个`独立的进程`。其原理是 **哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 1]  
这里的哨兵有 **两个作用**：

*  通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
 *  当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

**然而一个哨兵进程对Redis服务器进行监控，可能会出现问题**，为此，我们可以使用`多个哨兵`进行监控。各个哨兵之间还会进行监控，这样就形成了`多哨兵模式`。

**故障切换（failover）的过程**：假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程， **仅仅是哨兵1主观的认为主服务器不可用，这个现象成为 主观下线。 当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为 客观下线。** 这样对于客户端而言，一切都是透明的，客户端并不知晓。**切换后，主备redis配置文件6379.conf和主备redis的sentinel.conf的内容都会发生改变，即主redis的6379.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换。**

监控同一个Master的Sentinel会自动连接，组成一个分布式的Sentinel系统，互相通信并交换彼此关于被监视服务器的信息。

**Sentinel状态持久化**

`snetinel的状态会被持久化地写入sentinel的配置文件中`。每次当收到一个新的配置时，或者新创建一个配置时，配置会被持久化到硬盘中，并带上配置的版本戳。这意味着，**可以安全的停止和重启sentinel进程**。

## 4、工作方式 ##

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

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

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

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

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

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

7）**若没有足够数量的Sentinel同意Master已经下线，Master的客观下线状态就会被**`移除`。 若 Master重新向Sentinel 的PING命令返回有效回复，Master的主观下线状态就会被移除。

**定时任务**  
sentinel在内部有**3个定时任务**：

1）每10秒每个sentinel会对master和slave执行info命令，这个任务达到两个目的：

*  发现slave节点
 *  确认主从关系

2）每2秒每个sentinel通过master节点的channel交换信息（pub/sub）。master节点上有一个发布订阅的频道(sentinel:hello)。sentinel节点通过\_\_sentinel\_\_:hello频道进行信息交换(对节点的"看法"和自身的信息)，达成共识。  
3）每1秒每个sentinel对其他sentinel和redis节点执行ping操作（相互监控），这个其实是一个心跳检测，是失败判定的依据。

## 5、配置文件 ##

1）`sentinel monitor <masterName> <ip> <port> <quorum>`

四个参数含义：  
masterName这个是对某个master+slave组合的一个区分标识（一套sentinel是可以监听多套master+slave这样的组合的）。**ip 和 port 就是master节点的 ip 和 端口号**。  
**quorum这个参数是进行`客观下线`的一个依据**，意思是`至少有 quorum 个sentinel主观的认为这个master有故障`，才会对这个master进行下线以及故障转移(fileover)。因为有的时候，某个sentinel节点可能因为自身网络原因，导致无法连接master，而此时master并没有出现故障，所以这就需要多个sentinel都一致认为该master有问题，才可以进行下一步操作，这就保证了公平性和高可用。

2）`sentinel down-after-milliseconds <masterName> <timeout>`

**这个配置其实就是进行`主观下线`的一个依据**，masterName这个参数不用说了，timeout是一个毫秒值，表示：**如果这台sentinel超过timeout这个时间都无法连通master包括slave（slave不需要客观下线，因为不需要故障转移）的话，就会主观认为该master已经下线（实际下线需要客观下线的判断通过才会下线）**

**那么，多个sentinel之间是如何达到共识的呢？**

这就是依赖于前面说的第二个定时任务，某个sentinel先将master节点进行一个`主观下线`，然后会将这个判定通过sentinel is-master-down-by-addr这个命令问对应的节点是否也同样认为该addr的master节点要做`客观下线`。最后当达成这一共识的sentinel个数达到前面说的quorum设置的这个值时，就会对该master节点下线进行故障转移。**quorum的值一般设置为sentinel个数的二分之一加1，例如3个sentinel就设置2。**

# 二、搭建Redis哨兵模式 #

在上一篇博客主从复制的基础上搭建哨兵模式。

**实验环境**

<table> 
 <thead> 
  <tr> 
   <th>主机名（ip）</th> 
   <th>角色</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>server1（172.25.2.1）</td> 
   <td>redis-master</td> 
  </tr> 
  <tr> 
   <td>server2（172.25.2.2）</td> 
   <td>redis-slave</td> 
  </tr> 
  <tr> 
   <td>server3（172.25.2.3）</td> 
   <td>redis-slave</td> 
  </tr> 
 </tbody> 
</table>

1、将哨兵配置文件`sentinel.conf`复制到`/etc/redis/` ，修改配置文件`/etc/redis/sentinel.conf`

cd redis-5.0.3
    ls
    cp sentinel.conf /etc/redis
    cd /etc/redis/
    vim sentinel.conf 
    
    修改如下内容：
        17 protected-mode no	#关闭保护模式
    
        121 sentinel monitor mymaster 172.25.254.1 6379 2
    #指定要监控的master，mymaster是定义的master名字，quorum为法定票数2，此处指的是sentinel的数， 只有指定的sentinel同意时才认为sentinel做的决策是有效的，一般大于sentinel数量的半数。可以有多个master，一组sentinel集群可以监控N个主从复制架构 
    
        146 sentinel down-after-milliseconds mymaster 10000
    #至少多长时间连不上才认为master离线了。单位为ms，即连接超时时长（这里我设置为10秒）

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 2]  
修改完成后发送给两个slave节点：

scp sentinel.conf  server2:/etc/redis
    scp sentinel.conf  server3:/etc/redis

*  将server1上配好的sentinel文件发送给server2和server3，一定要在server1开启sentinel之前。这是因为sentinel是一个动态的服务。如果开启sentinel，然后再发送，那么sentinel配置文件就不会发生改变。这时，在server2上启动sentinel会报错。

测试：  
在三个redis上分别开启监控：

redis-server /etc/redis/sentinel.conf --sentinel

*  注意启动的顺序。首先是主机（server1）的Redis服务进程，然后启动从机的服务进程，最后启动3个哨兵的服务进程。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 3]  
    再开启一个shell连接server1查看信息：

redis-cli
    127.0.0.1:6379> info	#可以看到此是sercer1为master

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

redis-cli -p 26379
    127.0.0.1:26379> info	#可以看到监控信息

![在这里插入图片描述][20200323212813683.png]  
手动宕掉master的redis：

redis-cli
    127.0.0.1:6379> SHUTDOWN

![在这里插入图片描述][20200323212859839.png]  
等待10s后，在监控页面可以看到：server1宕掉，而server3变成新的master的信息  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 5]  
<font color=\#orange再开启一个shell连接server3查看信息：

redis-cli
    127.0.0.1:6379> info	#可以看到此时server3为master，而server2为slave

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

redis-cli	#可以添加信息
    127.0.0.1:6379> get name
    "nigar"
    127.0.0.1:6379> set age 20
    OK
    127.0.0.1:6379> get age
    "20"

![在这里插入图片描述][20200323213055530.png]  
此时会发现mster和slave的redis配置文件6379.conf和哨兵配置文件sentinel.conf内容均发生变化：

**在server1上：**

vim /etc/redis/6379.conf

自动添加最后一行，表明server1是server3的slave  
![在这里插入图片描述][20200323213442162.png]

vim /etc/redis/sentinel.conf

文件最后自动添加了，sentinel监控状况  
![在这里插入图片描述][20200323213535693.png]  
**在server3上：**

vim /etc/redis/6379.conf

![在这里插入图片描述][20200323213747582.png]  
server3中的redis配置文件中的redis配置信息已经被删除，server3上升为master。  
同理·，server2中的redis配置文件`6379.conf`，自动更新master的ip，以及监控文件`sentinel.conf`内容也已经改变

#### 解读6379.conf 文件中部分参数信息 ####

vim 6379.conf

由下至上看：表示内存到磁盘刷新数据的频率
    219 一个键发生变化时 900秒会更新
    220 10个键发生变化时 300秒会更新
    221 一万个键发生变化时 60秒会更新
    每60s，先看有没有10000个键发生变化，如果有就更新；
    如果没有，300秒后看有没有10个键发生变化，如果有就更新；
    如果没有，900秒后看有没有1个键发生变化，如果有就更新

![在这里插入图片描述][20200323213148963.png]

# 三、故障转移的具体步骤： #

**1）从下线的主服务的所有从服务里面挑选一个从服务，将其转成主服务**  
sentinel状态数据结构中保存了主服务的所有从服务信息，领头sentinel按照如下的规则从从服务列表中挑选出新的主服务；  
删除列表中处于下线状态的从服务；  
删除最近5秒没有回复过领头sentinel info信息的从服务；  
删除与已下线的主服务断开连接时间超过 down-after-milliseconds\*10毫秒的从服务，这样就能保留从的数据比较新（没有过早的与主断开连接）；  
领头sentinel从剩下的从列表中选择优先级高的，如果优先级一样，选择偏移量最大的（偏移量大说明复制的数据比较新），如果偏移量一样，选择运行id最小的从服务。

**2）已下线主服务的所有从服务改为复制新的主服务**  
挑选出新的主服务之后，领头sentinel 向原主服务的从服务发送 slaveof 新主服务 的命令，复制新master。

**3）将已下线的主服务设置成新的主服务的从服务，当其回复正常时，复制新的主服务，变成新的主服务的从服务**  
同理，当已下线的服务重新上线时，sentinel会向其发送slaveof命令，让其成为新主的从。

**温馨提示：** 还可以向任意sentinel发生sentinel failover 进行手动故障转移，这样就不需要经过上述主客观和选举的过程

*  [更详细总结][Link 1]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70]: /images/20230528/bb05470954eb45d6abf7c47bf15c3e8f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 1]: /images/20230528/5c95324e530c42438583588aa06e6cb4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 2]: /images/20230528/6e9169aafa0741db9ad3253eb1af9448.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 3]: /images/20230528/cbbdad349bbc4c8fb7594f0c4bbe4d81.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 4]: /images/20230528/cf4c898580364e15a95ee6cd4b7d286f.png
[20200323212813683.png]: /images/20230528/242747c86eae4d7f9be1c48f77e2454f.png
[20200323212859839.png]: /images/20230528/0c5fd04835c7492c8c2e4a4800a674d5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 5]: /images/20230528/54ec782d227f43759a26cbf0e456102e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 6]: /images/20230528/13a8657b987b4213ab0cb0bf29142031.png
[20200323213055530.png]: /images/20230528/9ed79b2a6f964ec0b4c99aa66877e785.png
[20200323213442162.png]: /images/20230528/5e519b2c15fb43b5a262d7284ace097f.png
[20200323213535693.png]: /images/20230528/83bca39071804a3f89acc1ef5db38438.png
[20200323213747582.png]: /images/20230528/68f079d65d3343d08eba17f4808e5f71.png
[20200323213148963.png]: /images/20230528/d4614f90504c4c7984127791f9568cee.png
[Link 1]: https://www.cnblogs.com/kevingrace/p/9004460.html