主从模式的弊端就是不具备高可用性，当master挂掉以后，Redis将不能再对外提供写入操作，因此sentinel模式应运而生。sentinel中文含义为哨兵，顾名思义，它的作用就是监控redis集群的运行状况，此模式具有如下一些特点：
- sentinel模式是建立在主从模式的基础上，如果只有一个Redis节点，sentinel就没有任何意义；
- 当master挂了以后，sentinel会在slave中选择一个做为master，并修改它们的配置文件，其他slave的配置文件也会被修改，比如slaveof属性会指向新的master；
- 当master重新启动后，它将不再是master，而是做为slave接收新的master的同步数据；
- sentinel因为也是一个进程，所以有挂掉的可能，所以sentinel也会启动多个形成一个sentinel集群；
- 多sentinel配置的时候，sentinel之间也会自动监控；
- 当主从模式配置密码时，sentinel也会同步将配置信息修改到配置文件中；
- 一个sentinel或sentinel集群可以管理多个主从Redis，多个sentinel也可以监控同一个redis；
- sentinel最好不要和Redis部署在同一台机器，不然Redis的服务器挂了以后，sentinel也可能会挂掉。
下面是Sentinel（哨兵）模式的工作的原理图：
其工作的流程如下所示：
- 每个sentinel以每秒钟一次的频率向它所知的master，slave以及其他sentinel实例发送一个 PING 命令；
- 如果一个实例距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被sentinel标记为主观下线；
- 如果一个master被标记为主观下线，则正在监视这个master的所有sentinel要以每秒一次的频率确认master的确进入了主观下线状态；
- 当有足够数量的sentinel（大于等于配置文件指定的值）在指定的时间范围内确认master的确进入了主观下线状态， 则master会被标记为客观下线；
- 在一般情况下， 每个sentinel会以每 10 秒一次的频率向它已知的所有master，slave发送 INFO 命令； - 当master被sentinel标记为客观下线时，sentinel向下线的master的所有slave发送 INFO 命令的频率会从 10 秒一次改为 1 秒一次；
- 若没有足够数量的sentinel同意master已经下线，master的客观下线状态就会被移除；若master重新向sentinel的 PING 命令返回有效回复，master的主观下线状态就会被移除。
#环境说明
| IP | 主机名 | 角色 |
|---|---|---|
| 192.168.182.110 | local-168-182-110 | master, sentinel |
| 192.168.182.111 | local-168-182-111 | slave1, sentinel |
| 192.168.182.112 | local-168-182-112 | slave2, sentinel |
同时，为了保证能够最小可能的碟机事件，sentinel 最好跟redis部署在不同的机器上，sentinel 端口：26379。
#配置sentinel
因为哨兵模式是基于主从模式的，所以redis的相关配置就不多说明。我们只需要在主从模式的基础上直接修改sentinel配置文件，配置3个哨兵即可，哨兵的配置可以参考如下内容。
# 三个节点创建存储目录
mkdir /opt/software/redis-7.0.3/sentinel
mkdir /opt/software/redis-7.0.3/sentinel ; chown -R redis:redis /opt/software/redis-7.0.3/
cat >/usr/local/redis/sentinel.conf<<EOF
daemonize yes
logfile "/usr/local/redis/sentinel.log"
# sentinel工作目录
dir "/opt/software/redis-7.0.3/sentinel"
# 判断master失效至少需要2个sentinel同意，建议设置为n/2+1，n为sentinel个数
# sentinel monitor <master-name> <ip> <port> <count>
sentinel monitor mymaster 192.168.182.110 6379 2
sentinel auth-pass mymaster 123456
# 判断master主观下线时间，默认30s
sentinel down-after-milliseconds mymaster 30000
EOF
启动sentinel
启动sentinel模式的命令如下：
/usr/local/bin/redis-sentinel /usr/local/redis/sentinel.conf
netstat -tnlp|grep 26379
故障模拟测试
为了模拟故障，我们将master停掉。
# 停掉master
systemctl stop redis
redis-cli -h 192.168.182.111 -a 123456 info replication
可以看到，Redis发现master节点出现问题后，会自动切换到其它节点。接下来，我们再测试一下读写。
[root@local-168-182-110 redis-7.0.3]# redis-cli -h 192.168.182.112 -a 123456
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
192.168.182.112:6379> set k2 v2
OK
可以看到，新的master节点读写能力都是正常的，接下来就是恢复故障，看能否正常。
redis-cli -h 192.168.182.112 -a 123456 info replication
可以看到，和之前预定的sentinel模式的工作流程是一样的：原先的master节点在恢复后并不会主动切换到master角色，而是作为slave角色继续服务。
