Sentinel模式介绍
主从模式的弊端就是不具备高可用性，当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以每秒钟一次的频率向它所知的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的主观下线状态就会被移除

 ####每台机器都需要安装

cd /data/
wget https://download.redis.io/releases/redis-6.2.6.tar.gz
tar -zxvf redis-6.2.6.tar.gz
mv redis-6.2.6 redis
cd redis
make
make install
useradd -s /sbin/nologin redis
chown -R redis:redis /data/redis -R

redis sentinel集群架构图

 #配置主从，下文已1组主从为例，其它的更改端口号配置即可

10.2.33.94 6379 master
mkdir /data/redis/6379/
cp /data/redis/redis.conf /data/redis/6379/redis6379.conf 
chown redis.redis /data/redis/6379 -R
vim /data/redis/6379/redis6379.conf 
logfile /data/redis/6379/redis6379.log	#日志路径
daemonize yes				#允许后台启动
bind 0.0.0.0				#监听ip，多个ip用空格分隔,这里为了方便就直接全部了，生成环境请按情况配置
dir /data/redis/6379			#数据库备份文件存放目录
masterauth      redis123456		#slave连接master密码，可省略
requirepass redis123456			#设置连接密码，slave可省略
appendonly yes				#在备份目录生成appendonly.aof文件，将每次操作请求追加到文件
 
sudo -u redis /usr/local/bin/redis-server /data/redis/6379/redis6379.conf &


10.2.33.95 6379 slave
mkdir /data/redis/6379/
cp /data/redis/redis.conf /data/redis/6379/redis6379.conf 
chown redis.redis /data/redis/6379 -R
vim /data/redis/6379/redis6379.conf 
daemonize yes	
logfile /data/redis/6379/redis6379.log
dir /data/redis/6379
slaveof	10.2.33.94 6379
requirepass redis123456	
masterauth      redis123456
appendonly yes

sudo -u redis /usr/local/bin/redis-server /data/redis/6379/redis6379.conf &

94上验证
[root@10-2-33-94 redis]# redis-cli 
127.0.0.1:6379> auth redis123456
OK
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=10.2.33.95,port=6379,state=online,offset=70,lag=0
master_failover_state:no-failover
master_replid:e037ae6cb2e6e509cdcc6edce5373d95fd866b45
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:70
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:70
127.0.0.1:6379> 

#以上为一组redis配置过程，其它两组更改端口，写对M-S对应ip即可

#配置sentinel,已一台为例，其它更改端口即可

10.2.33.97 26379
mkdir /data/redis/26379/
cp /data/redis/sentinel.conf /data/redis/26379/sentinel26379.conf
vim /data/redis/26379/sentinel26379.conf
daemonize yes
logfile "/data/redis/26379/sentinel26379.log"
dir "/data/redis/26379"
sentinel monitor mymaster 10.2.33.94 6379 2                 #判断master失效至少需要2个sentinel同意，建议设置为n/2+1，n为sentinel个数
sentinel auth-pass mymaster redis123456
sentinel down-after-milliseconds mymaster 30000             #判断master主观下线时间，默认30s

sudo -u redis /usr/local/bin/redis-sentinel /data/redis/26379/sentinel26379.conf &

#以上为一胎redis sentinel配置过程，其它两组更改端口，写对M-S对应ip即可
注：sentinel26379.conf 文件在服务启动后会在最后面追加以下信息，
其中集群中的sentinel myid是不相同的随机生成的，有问题的话删除该行，重启服务即可自动生成

protected-mode no
user default on nopass sanitize-payload ~* &* +@all
sentinel config-epoch mymaster 2
sentinel leader-epoch mymaster 2
sentinel current-epoch 2
sentinel known-replica mymaster 10.2.33.95 6379
sentinel myid 296028c7536c335681f5ab63a71cd70a2ee48774

 sentinel集群检测，在任一台登陆查询：

# redis-cli -P 26379
Unrecognized option or bad number of args for: '-P'
# redis-cli -p 26379
127.0.0.1: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=10.2.33.94:6379,slaves=1,sentinels=3

##注最后一行记录了Master信息，有几个slave，sentinel集群有几台服务器

模拟故障，直接kill掉master进程

[root@10-2-33-94 ~]# ps -ef|grep redis
redis    10133     1  0 14:45 ?        00:00:01 /usr/local/bin/redis-server 0.0.0.0:6379
root     19374  8357  0 14:57 pts/0    00:00:00 grep --color=auto redis
[root@10-2-33-94 ~]# kill -9 10133

哨兵上的日志

9321:X 24 Nov 2021 14:58:22.888 # +sdown master mymaster 10.2.33.94 6379		###master服务已经宕机
9321:X 24 Nov 2021 14:58:22.972 # +odown master mymaster 10.2.33.94 6379 #quorum 2/2	###sentinel集群中有超过2个都认为其宕机，转为客观宕机odown
9321:X 24 Nov 2021 14:58:22.972 # +new-epoch 3		###递增集群状态版本号，这个版本号将被接下来选举出的新的master采用
9321:X 24 Nov 2021 14:58:22.972 # +try-failover master mymaster 10.2.33.94 6379		###开始故障恢复
9321:X 24 Nov 2021 14:58:22.973 # +vote-for-leader 8657f2bc325686d5a631c4f603846460baf657a1 3	###投票选举哨兵leader，有3个哨兵需要投票，第一个选举自己后面为配置文件中的myid
9321:X 24 Nov 2021 14:58:22.977 # 8e30671f4b2b329c69a2f52efe8eed7adde7b939 voted for 8657f2bc325686d5a631c4f603846460baf657a1 3		###第二个开启投票支持
9321:X 24 Nov 2021 14:58:22.977 # 296028c7536c335681f5ab63a71cd70a2ee48774 voted for 8657f2bc325686d5a631c4f603846460baf657a1 3		###第三个开启投票支持
9321:X 24 Nov 2021 14:58:23.074 # +elected-leader master mymaster 10.2.33.94 6379	###哨兵集群再次确认进行故障转移服务	
9321:X 24 Nov 2021 14:58:23.074 # +failover-state-select-slave master mymaster 10.2.33.94 6379	###开始再集群中寻找合适的slave
9321:X 24 Nov 2021 14:58:23.132 # +selected-slave slave 10.2.33.95:6379 10.2.33.95 6379 @ mymaster 10.2.33.94 6379	###找到合适的slave作为新的master
9321:X 24 Nov 2021 14:58:23.132 * +failover-state-send-slaveof-noone slave 10.2.33.95:6379 10.2.33.95 6379 @ mymaster 10.2.33.94 6379	###向该slave发送slaveof-noone指令，完成slave到master转换
9321:X 24 Nov 2021 14:58:23.204 * +failover-state-wait-promotion slave 10.2.33.95:6379 10.2.33.95 6379 @ mymaster 10.2.33.94 6379	###等待其它sentinel确认slave
9321:X 24 Nov 2021 14:58:23.412 # +promoted-slave slave 10.2.33.95:6379 10.2.33.95 6379 @ mymaster 10.2.33.94 6379	###slave意味着其它的sentinel全部确认成功
9321:X 24 Nov 2021 14:58:23.412 # +failover-state-reconf-slaves master mymaster 10.2.33.94 6379		###开始对集群中所有的slave做reconf更新配置操作
9321:X 24 Nov 2021 14:58:23.473 # +failover-end master mymaster 10.2.33.94 6379		###因为只有1主1从，故障转移结束,如果多个从会向其它slave发送slaveof,使其指向新master
9321:X 24 Nov 2021 14:58:23.473 # +switch-master mymaster 10.2.33.94 6379 10.2.33.95 6379	###各个sentinel开始监控新的master
9321:X 24 Nov 2021 14:58:23.473 * +slave slave 10.2.33.94:6379 10.2.33.94 6379 @ mymaster 10.2.33.95 6379	###添加94为新进master95的从
9321:X 24 Nov 2021 14:58:53.501 # +sdown slave 10.2.33.94:6379 10.2.33.94 6379 @ mymaster 10.2.33.95 6379	###94已经宕机，等待恢复

#注：94恢复后会成为95的从。手动恢复94查看日志

哨兵日志

20818:X 24 Nov 2021 15:20:49.328 * +convert-to-slave slave 10.2.33.94:6379 10.2.33.94 6379 @ mymaster 10.2.33.95 6379  ####94已恢复，并作为95的从

其它端口的配置按照如上修改即可，本文略