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部署

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

分别有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 6379
daemonize yes
logfile "6379.log"
dbfilename "dump-6379.rdb"
dir "/var/redis/data/"

启动主节点

1	➜ sudo redis-server redis-6379.conf

使用PING命令检测是否启动

1 2	➜ 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      // 从属主节点

启动两个从节点

1 2	➜ 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
......

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
* 确认

➜ 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表示启


部署三个Sentinel节点之后，真个拓扑结构如图所示：
[img02]
* 当部署号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

1
2
3


## 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]

1 2	我们干掉端口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）的判断，确认主节点不可达，则通知从节点中止复制主节点的操作。
[img03]
当主节点下线时长超过配置的下线时长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”
…………..

1 2	看一下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的旧主节点断开连接。如图所示：
[img04]
我们在试着重启端口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

1
2


看看发生什么：

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的从节点。
[img05]

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

不要因为走得太远，就忘记为什么而出发

Redis Sentinel 介绍与部署