Redis 学习笔记（十三）Redis Sentinel 介绍与部署

Redis Sentinel 介绍与部署

1. Sentinel介绍

1.1 主从复制的问题

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

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

但是问题来了：

• 一旦主节点宕机，从节点晋升成主节点，同时需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点，整个过程需要人工干预。
• 主节点的写能力受到单机的限制。
• 主节点的存储能力受到单机的限制。

第一个问题，我们接下来讲的Sentinel就可以解决。而后两个问题，Redis也给出了方案Redis Cluster。

1.2 Redis Sentinel的高可用

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

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

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

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

2. Redis Sentinel部署

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

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

role IP port master 127.0.0.1 6379 slave1 127.0.0.1 6380 slave2 127.0.0.1 6381 Sentinel1 127.0.0.1 26379 Sentinel2 127.0.0.1 26380 Sentinel3 127.0.0.1 26381

2.1 启动主节点

• 配置：

port 6379daemonize yeslogfile "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 pingPONG

2.2 启动两个从节点

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

port 6380daemonize yeslogfile "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 pingPONG➜   redis-cli -h 127.0.0.1 -p 6381 pingPONG

2.3 确认主从关系

• 主节点视角

➜   redis-cli -h 127.0.0.1 -p 6379 INFO replication# Replicationrole:masterconnected_slaves:2slave0:ip=127.0.0.1,port=6380,state=online,offset=85,lag=0slave1: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# Replicationrole:slavemaster_host:127.0.0.1master_port:6379master_link_status:up......

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

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领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，限制每次向新的主节点发起复制操作的从节点个数为1sentinel 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# Sentinelsentinel_masters:1sentinel_tilt:0sentinel_running_scripts:0sentinel_scripts_queue_length:0sentinel_simulate_failure_flags:0master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=1 //sentinels=1表示启动了1个Sentinel

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

• 当部署号Redis Sentinel之后，会有如下变化
  
  • Sentinel节点自动发现了从节点、其余Sentinel节点。
  • 去掉了默认配置，例如：parallel-syncs、failover-timeout。
  • 新添加了纪元（epoch）参数。

我们拿端口26379的举例，启动所有的Sentinel和数据节点后，配置文件如下：

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

2.5 故障转移实验

先查看一下节点的进程pid

➜   ps -aux | grep redisroot     18225  0.1  0.0  40208 11212 ?        Ssl  22:10   0:05 redis-server 127.0.0.1:6379root     18234  0.0  0.0  38160  8364 ?        Ssl  22:10   0:04 redis-server 127.0.0.1:6380root     18244  0.0  0.0  38160  8308 ?        Ssl  22:10   0:04 redis-server 127.0.0.1:6381root     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 redisroot     18234  0.0  0.0  38160  8364 ?        Ssl  22:10   0:05 redis-server 127.0.0.1:6380root     18244  0.0  0.0  38160  8308 ?        Ssl  22:10   0:05 redis-server 127.0.0.1:6381root     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）的判断，确认主节点不可达，则通知从节点中止复制主节点的操作。

当主节点下线时长超过配置的下线时长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 mymaster1)  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的旧主节点断开连接。如图所示：

我们在试着重启端口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:6380root     18244  0.1  0.0  40208 10356 ?        Ssl  5月22   0:07 redis-server 127.0.0.1:6381root     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 mymaster1)  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的从节点。

从上面的逻辑架构和故障转移试验中，可以看出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。