Redis Sentinel 介绍与部署

谁借莪１个温暖的怀抱￠ 2022-04-23 06:34 176阅读 0赞

# Redis Sentinel 介绍与部署 #

## 1. Sentinel介绍 ##

### 1.1 主从复制的问题 ###

Redis主从复制可将主节点数据同步给从节点，从节点此时有两个作用：

1.  一旦主节点宕机，从节点作为主节点的备份可以随时顶上来。
2.  扩展主节点的读能力，分担主节点读压力。

但是问题来了：

一旦主节点宕机，从节点晋升成主节点，同时需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点，整个过程需要人工干预。  
主节点的写能力受到单机的限制。  
主节点的存储能力受到单机的限制。  
第一个问题，我们接下来讲的Sentinel就可以解决。而后两个问题，Redis也给出了方案Redis Cluster。

### 1.2 Redis Sentinel的高可用 ###

Redis Sentinel是一个分布式架构，包含若干个Sentinel节点和Redis数据节点，每个Sentinel节点会对数据节点和其余Sentinel节点进行监控，当发现节点不可达时，会对节点做下线标识。

如果被标识的是主节点，他还会选择和其他Sentinel节点进行“协商”，当大多数的Sentinel节点都认为主节点不可达时，他们会选举出一个Sentinel节点来完成自动故障转移工作，同时将这个变化通知给Redis应用方。

整个过程完全自动，不需要人工介入，所以可以很好解决Redis的高可用问题。

接下来我们就通过部署一个Redis Sentinel实例来了解整体框架。

## 2. Redis Sentinel部署 ##

我们部署的拓扑结构如图所示：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTIwNDUwNDU_size_16_color_FFFFFF_t_70][]

分别有3个Sentinel节点，1个主节点，2个从节点组成一个Redis Sentinel。

<table style="width:500px;"> 
 <tbody> 
  <tr> 
   <td>role</td> 
   <td>IP</td> 
   <td>port</td> 
  </tr> 
  <tr> 
   <td>master</td> 
   <td>127.0.0.1</td> 
   <td>6379</td> 
  </tr> 
  <tr> 
   <td>slave1</td> 
   <td>127.0.0.1</td> 
   <td>6380</td> 
  </tr> 
  <tr> 
   <td>slave2</td> 
   <td>127.0.0.1</td> 
   <td>6381</td> 
  </tr> 
  <tr> 
   <td>Sentinel1</td> 
   <td>127.0.0.1</td> 
   <td>26379</td> 
  </tr> 
  <tr> 
   <td>Sentinel2</td> 
   <td>127.0.0.1</td> 
   <td>26380</td> 
  </tr> 
  <tr> 
   <td>Sentinel3</td> 
   <td>127.0.0.1</td> 
   <td>26381</td> 
  </tr> 
 </tbody> 
</table>

###    2.1 启动主节点 ###

配置：

port 6379
    daemonize yes
    logfile "6379.log"
    dbfilename "dump-6379.rdb"
    dir "/var/redis/data/"

启动主节点  
➜

sudo redis-server redis-6379.conf

使用PING命令检测是否启动  
➜

redis-cli -h 127.0.0.1 -p 6379 ping
    PONG

2.2 启动两个从节点

配置（两个从节点配置相同，除了文件名有区分）

port 6380
    daemonize yes
    logfile "6380.log"
    dbfilename "dump-6380.rdb"
    dir "/var/redis/data/" 
    slaveof 127.0.0.1 6379      // 从属主节点

启动两个从节点

➜   sudo redis-server redis-6380.conf 
    ➜   sudo redis-server redis-6381.conf

使用PING命令检测是否启动

➜   redis-cli -h 127.0.0.1 -p 6380 ping
    PONG
    ➜   redis-cli -h 127.0.0.1 -p 6381 ping
    PONG

2.3 确认主从关系

主节点视角  
➜

redis-cli -h 127.0.0.1 -p 6379 INFO replication

# Replication
    role:master
    connected_slaves:2
    slave0:ip=127.0.0.1,port=6380,state=online,offset=85,lag=0
    slave1:ip=127.0.0.1,port=6381,state=online,offset=85,lag=0
    ......

从节点视角（6380端口）  
➜

redis-cli -h 127.0.0.1 -p 6380 INFO replication

# Replication
    role:slave
    master_host:127.0.0.1
    master_port:6379
    master_link_status:up
    ......

确立中从关系，如下图所示：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTIwNDUwNDU_size_16_color_FFFFFF_t_70 1][]

### 2.4 部署Sentinel节点 ###

3个Sentinel节点的部署方法是相同的（端口不同）。以26379为例。配置

// Sentinel节点的端口
    port 26379  
    dir /var/redis/data/
    logfile "26379.log"
    
    // 当前Sentinel节点监控 127.0.0.1:6379 这个主节点
    // 2代表判断主节点失败至少需要2个Sentinel节点节点同意
    // mymaster是主节点的别名
    sentinel monitor mymaster 127.0.0.1 6379 2
    
    //每个Sentinel节点都要定期PING命令来判断Redis数据节点和其余Sentinel节点是否可达，如果超过30000毫秒且没有回复，则判定不可达
    sentinel down-after-milliseconds mymaster 30000
    
    //当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，限制每次向新的主节点发起复制操作的从节点个数为1
    sentinel parallel-syncs mymaster 1
    
    //故障转移超时时间为180000毫秒
    sentinel failover-timeout mymaster 180000

启动（两种方法）

redis-sentinel sentinel-26379.conf

redis-server sentinel-26379.conf --sentinel

sudo redis-sentinel sentinel-26379.conf --sentinel  
  
确认  
➜

redis-cli -h 127.0.0.1 -p 26379 INFO Sentinel

# Sentinel
    sentinel_masters:1
    sentinel_tilt:0
    sentinel_running_scripts:0
    sentinel_scripts_queue_length:0
    sentinel_simulate_failure_flags:0
    master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=1 //sentinels=1表示启动了1个Sentinel

部署三个Sentinel节点之后，真个拓扑结构如图所示：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTIwNDUwNDU_size_16_color_FFFFFF_t_70 2][]

当部署号Redis Sentinel之后，会有如下变化   
Sentinel节点自动发现了从节点、其余Sentinel节点。  
去掉了默认配置，例如：parallel-syncs、failover-timeout。  
新添加了纪元（epoch）参数。  
我们拿端口26379的举例，启动所有的Sentinel和数据节点后，配置文件如下：

port 26379
    dir "/var/redis/data"
    sentinel myid 70a3e215c1a34b4d9925d170d9606e615a8874f2
    sentinel monitor mymaster 127.0.0.1 6379 2
    sentinel config-epoch mymaster 0
    sentinel leader-epoch mymaster 0
    daemonize yes
    logfile "26379.log"
    // 发现了两个从节点
    sentinel known-slave mymaster 127.0.0.1 6381
    sentinel known-slave mymaster 127.0.0.1 6380
    // 发送了连个Sentinel节点
    sentinel known-sentinel mymaster 127.0.0.1 26381 e1148ad6caf60302dd6d0dbd693cb3448e209ac2
    sentinel known-sentinel mymaster 127.0.0.1 26380 39db5b040b21a52da5334dd2d798244c034b4fc3
    sentinel current-epoch 0

###    2.5 故障转移实验 ###

先查看一下节点的进程pid

➜

ps -aux | grep redis

root     18225  0.1  0.0  40208 11212 ?        Ssl  22:10   0:05 redis-server 127.0.0.1:6379
    root     18234  0.0  0.0  38160  8364 ?        Ssl  22:10   0:04 redis-server 127.0.0.1:6380
    root     18244  0.0  0.0  38160  8308 ?        Ssl  22:10   0:04 redis-server 127.0.0.1:6381
    root     20568  0.1  0.0  38160  8460 ?        Ssl  23:05   0:02 redis-sentinel *:26379 [sentinel]
    root     20655  0.1  0.0  38160  8296 ?        Ssl  23:07   0:02 redis-sentinel *:26380 [sentinel]
    root     20664  0.1  0.0  38160  8312 ?        Ssl  23:07   0:02 redis-sentinel *:26381 [sentinel]

我们干掉端口6379的主节点。

➜   sudo kill -9 18225  
➜   ps -aux | grep redis

root     18234  0.0  0.0  38160  8364 ?        Ssl  22:10   0:05 redis-server 127.0.0.1:6380
    root     18244  0.0  0.0  38160  8308 ?        Ssl  22:10   0:05 redis-server 127.0.0.1:6381
    root     20568  0.1  0.0  38160  8460 ?        Ssl  23:05   0:03 redis-sentinel *:26379 [sentinel]
    root     20655  0.1  0.0  38160  8296 ?        Ssl  23:07   0:03 redis-sentinel *:26380 [sentinel]
    root     20664  0.1  0.0  38160  8312 ?        Ssl  23:07   0:03 redis-sentinel *:26381 [sentinel]

此时，Redis Sentinel对主节点进行客观下线（Objectively Down， 简称 ODOWN）的判断，确认主节点不可达，则通知从节点中止复制主节点的操作。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTIwNDUwNDU_size_16_color_FFFFFF_t_70 3][]

当主节点下线时长超过配置的下线时长30000秒，Redis Sentinel执行故障转移操作。

此时，我们查看一下Sentinel节点监控的主节点信息：

127.0.0.1:26379> sentinel masters   
1)  1) "name"  
    2) "mymaster"  
    3) "ip"  
    4) "127.0.0.1"  
    5) "port"  
    6) "6380"           //可以看到主节点已经成为6380端口的节点  
    7) "runid"  
    8) "084850ab4ff6c2f2502b185c8eab5bdd25a26ce2"  
    9) "flags"  
   10) "master"  
    ..............  
看一下Sentinel节点监控的从节点信息：

127.0.0.1:26379> sentinel slaves mymaster  
1)  1) "name"  
    2) "127.0.0.1:6379"             //ip:port  
    3) "ip"  
    4) "127.0.0.1"  
    5) "port"  
    6) "6379"  
    7) "runid"  
    8) ""  
    9) "flags"  
   10) "s\_down,slave,disconnected"  //端口6379的原主节点已经断开了连接  
   ..............  
2)  1) "name"  
    2) "127.0.0.1:6381"               
    3) "ip"  
    4) "127.0.0.1"  
    5) "port"  
    6) "6381"  
    7) "runid"  
    8) "24495fe180e4fd64ac47467e0b2652894406e9e4"  
    9) "flags"  
   10) "slave"                      //本来的从节点，还是从节点的role  
    ..............  
  
由以上信息可得，端口为6380的Redis数据节点成为新的主节点，端口为6379的旧主节点断开连接。如图所示：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTIwNDUwNDU_size_16_color_FFFFFF_t_70 4][]

我们在试着重启端口6379的数据节点。

➜   sudo redis-server redis-6379.conf   
➜   ps -aux | grep redis                
root     18234  0.1  0.0  40208 11392 ?        Ssl  5月22   0:06 redis-server 127.0.0.1:6380  
root     18244  0.1  0.0  40208 10356 ?        Ssl  5月22   0:07 redis-server 127.0.0.1:6381  
root     20568  0.1  0.0  38160  8460 ?        Ssl  5月22   0:05 redis-sentinel \*:26379 \[sentinel\]  
root     20655  0.1  0.0  38160  8296 ?        Ssl  5月22   0:05 redis-sentinel \*:26380 \[sentinel\]  
root     20664  0.1  0.0  38160  8312 ?        Ssl  5月22   0:05 redis-sentinel \*:26381 \[sentinel\]  
menwen   22475  0.0  0.0  14216  5920 pts/2    S+   5月22   0:00 redis-cli -p 26379  
// 6379的数据节点已重启  
root     22617  0.0  0.0  38160  8304 ?        Ssl  00:00   0:00 redis-server 127.0.0.1:6379     
  
看看发生什么：

127.0.0.1:26379> sentinel slaves mymaster  
1)  1) "name"  
    2) "127.0.0.1:6379"     //6379端口的节点重启后，变成了"活"的从节点  
    3) "ip"  
    4) "127.0.0.1"  
    5) "port"  
    6) "6379"  
    7) "runid"  
    8) "de1b5c28483cf150d9550f8e338886706e952346"  
    9) "flags"  
   10) "slave"  
    ..............  
2)  1) "name"               //6381端口的节点没有变化，仍是从节点  
    2) "127.0.0.1:6381"  
    ..............  
  
他被降级成为端口6380的从节点。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTIwNDUwNDU_size_16_color_FFFFFF_t_70 5][]

从上面的逻辑架构和故障转移试验中，可以看出Redis Sentinel的以下几个功能。

监控：Sentinel节点会定期检测Redis数据节点和其余Sentinel节点是否可达。  
通知：Sentinel节点会将故障转移通知给应用方。  
主节点故障转移：实现从节点晋升为主节点并维护后续正确的主从关系。  
配置提供者：在Redis Sentinel结构中，客户端在初始化的时候连接的是Sentinel节点集合，从中获取主节点信息。  
3. Sentinel配置说明

sentinel monitor mymaster 127.0.0.1 6379 2
    
    当前Sentinel节点监控 127.0.0.1:6379 这个主节点
    2代表判断主节点失败至少需要2个Sentinel节点节点同意
    mymaster是主节点的别名
    sentinel down-after-milliseconds mymaster 30000
    
    每个Sentinel节点都要定期PING命令来判断Redis数据节点和其余Sentinel节点是否可达，如果超过30000毫秒且没有回复，则判定不可达
    sentinel parallel-syncs mymaster 1
    
    当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，限制每次向新的主节点发起复制操作的从节点个数为1。
    sentinel failover-timeout mymaster 180000
    
    故障转移超时时间为180000
    sentinel auth-pass \ \ 
    如果Sentinel监控的主节点配置了密码，可以通过sentinel auth-pass配置通过添加主节点的密码，防止Sentinel节点无法对主节点进行监控。
    例如：sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
    sentinel notification-script \ \ 
    在故障转移期间，当一些警告级别的Sentinel事件发生（指重要事件，如主观下线，客观下线等）时，会触发对应路径的脚本，想脚本发送相应的事件参数。
    例如：sentinel notification-script mymaster /var/redis/notify.sh
    sentinel client-reconfig-script \ \ 
    在故障转移结束后，触发应对路径的脚本，并向脚本发送故障转移结果的参数。
    例如：sentinel client-reconfig-script mymaster /var/redis/reconfig.sh。

ps：目前知道的哨兵模式的几个问题；

1.如果把哨兵部署在主从服务器上面，每次请求都会经过哨兵，询问哨兵当前的主服务器是谁，然后转发给相应的服务器，可能会增加服务器的压力。所以条件允许的话，应该把哨兵单独拿出来放在哨兵服务器上面。

2.如果哨兵集合中其中一个服务器宕机了，不知道会不会影响监控，会不会影响主从服务器提供服务？答案：不会影响。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTIwNDUwNDU_size_16_color_FFFFFF_t_70]: /images/20220323/1339f0b877c243ffa6016657101e59af.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTIwNDUwNDU_size_16_color_FFFFFF_t_70 1]: /images/20220323/58ecfa6e042e41f08a308a448570a7f1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTIwNDUwNDU_size_16_color_FFFFFF_t_70 2]: /images/20220323/6707ed38675642cea311c081c210adfe.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTIwNDUwNDU_size_16_color_FFFFFF_t_70 3]: /images/20220323/d1590ac9abef4b02937ba0db9ce2ea49.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTIwNDUwNDU_size_16_color_FFFFFF_t_70 4]: /images/20220323/815d6411fd6948e792b09beee90592f3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTIwNDUwNDU_size_16_color_FFFFFF_t_70 5]: /images/20220323/5d0283fbc48a4bc38d6fc4f0a94a2269.png