一、sentinel基础
在Redis的主从复制中有一个问题很明显，比如说在一主三从的架构下，如果主节点宕机，那么所有的写操作也就不能执行了，这个主从复制架构也就瘫痪了，所以Redis引入了sentinel机制。
sentinel其实就是一个额外的主机，这个主机既可以提供监控，也可以提供配置的功能，也就是说他可以监控所有的主机状态，当主节点宕机，他可以自动的从所有的从节点中挑选一个将其升级为主节点，当产生了新的主节点之后，其他的性节点会向sentinel发送查询请求，查看当前主节点是哪个，以此来获得新的主节点。所以sentinel是Redis主从架构中，实现高可用的解决方案。
还有一个问题，如果是sentinel自己出了问题导致其检测不到主节点，但是主节点其实并没有出问题，这就会导致脑裂，所以为了解决这个问题，我们往往设置多个sentine节点，他们共同监控主节点，当有任意一台sentinel发现找不到主节点的时候，这些sentinel会相互商议并投票确定是否主节点真的出了问题，这样还能解决一个问题就是当某个sentinel出现故障，其他sentinel节点还可以继续监控主从复制架构。
需要注意的是，sentinel只监控主节点服务器，因为它会通过主服务器的信息发现各个从服务器节点，并将从服务器节点纳入到被监控节点中。
sentinel的配置文件
sentinel的专用配置文件：/etc/redis-sentinel.conf
sentinel的端口：26379
在这个配置文件中每个sentinel实例大概需要四项配置
- 设置所监控的主节点的信息
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 10.220.5.171 6379 2
说明：master-name
如果不是用主机名来唯一区分每个节点的话，这个名字可以随便写
如果监控多组主从的话这个名称应该不同
ip：主节点的IP地址
redis-port：主节点监听的端口
quorum：
这个数值是表明这个主节点至少拥有几票才能认为这个节点是有效的
如果只有一个sentinel节点的话，这个数值应该设置为1
通常sentinel节点建议设置为奇数个，这样这个数值可以设置成半数以上，这样才有意义（防止脑裂）
注意：一个sentinel集群，可以监控多组redis主从复制集群，所以上面这行代码配置可以出现多次
- 设置主节点多长时间没有信息认为其已经离线
# Default is 30 seconds.
sentinel down-after-milliseconds mymaster 30000
注意：这里的时间单位是毫秒，30000就是30秒
- 设置当主服务器宕机的时候，允许多少从服务器同时向sentinel发送链接请求。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
- 发生故障转移的超时时间
# Default is 3 minutes.
sentinel failover-timeout mymaster 180000
说明：这里就是设置在将从节点设置为主节点的时候，如果多久没有提升成功，就认为这次提升失败了。
启动sentinel方式
sentinel其实就是Redis的一个组件而已，在安装Redis的时候就已经自带了，就叫做redis-sentinel，另外，用redis-server启动时候指定选型 --sentinel，也可以实现启动sentinel。
需要注意的是在启动sentinel的时候，必须指定起自己的配置文件，这个配置文件会用于保存redis的配置信息。
总结启动方式有两种:
redis-sentinel /path/to/file.conf
redis-server /path/to/file.conf --sentinel
启动sentinel的步骤
- 初始化sentinel：运行redis-server专用于sentinel的代码
- 初始化sentinel的状态：根据配置文件，初始化天空master的主机列表
- 创建连接到主服务器的网络连接
sentinel的专用命令
SENTINEL master ：显示所有被监控的master节点
SENTINEL slaves <masterName>：获取指定主服务器的从节点
SENTINEL get-master--addr-by-name <masterName> ：根据名字来获取IP地址
SENTINEL reset ：清除sentinel的全部状态，包括正在执行的故障转移
SENTINEL failover：手动执行故障转移，也就是当主节点故障时，在不询问其他节点的情况下，强制执行故障转移
sentinel主观下线、客观下线概念
主观下线，也就是一个sentinel认为主节点下线了，对于这个sentinel来说主机下线在目前是主观下线，但是此时还需要征求其他sentinel的意见，如果所有的sentinel都认为这个主节点下线了，那么此时主观下线就变成了客观下线。
sentinel用于实现监控各个节点的方式就是，当master被sentinel监控之后，master每隔一秒向sentinel发送ping，用这个来作为心跳信息。
二、 演示：Redis复制的高可用
这里我来模拟一个一主两从的架构，可以在多个主机上来做，但是这里我用redis多实例来做，多个实例分别监听6379、6380、6381端口。
第一步：配置redis多实例
需要注意的是：在配置多实例的时候端口、pid文件、日志文件、数据文件路径、不能相同。
- 创建目录
[root@171 ~]# mkdir /redis/{6379,6380,6381} -pv
[root@171 ~]# cp /etc/redis.conf /redis/6379/redis1.conf
[root@171 ~]# cp /etc/redis.conf /redis/6380/redis2.conf
[root@171 ~]# cp /etc/redis.conf /redis/6381/redis3.conf
[root@171 ~]# chown -R redis.redis /redis
- 编辑配置文件
# 第一个节点配置
[root@171 ~]# vim /redis/6379/redis1.conf
port 6379
daemonize yes
pidfile /var/run/redis_6379.pid
logfile /var/log/redis/redis_6379.log
dir /redis/6379
# 第二个节点配置
[root@171 ~]# vim /redis/6380/redis2.conf
port 6380
daemonize yes
pidfile /var/run/redis_6380.pid
logfile /var/log/redis/redis_6380.log
dir /redis/6380
# 第三个节点配置
[root@171 ~]# vim /redis/6381/redis3.conf
port 6381
daemonize yes
pidfile /var/run/redis_6381.pid
logfile /var/log/redis/redis_6381.log
dir /redis/6381
- 启动服务
[root@171 ~]# redis-server /redis/6379/redis1.conf
[root@171 ~]# redis-server /redis/6380/redis2.conf
[root@171 ~]# redis-server /redis/6381/redis3.conf
[root@171 ~]# ss -tnl
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 10.220.5.171:6379 *:*
LISTEN 0 128 10.220.5.171:6380 *:*
LISTEN 0 128 10.220.5.171:6381 *:*
第二步：配置redis主从
将6379设置为主，6380 6381都设置为从
- 查看6379的复制状态
[root@171 ~]# redis-cli -h 10.220.5.171 -p 6379
10.220.5.171:6379> info replication
# Replication
role:master
connected_slaves:0
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:0
- 将6380的主设置为6379
[root@171 ~]# redis-cli -h 10.220.5.171 -p 6380
10.220.5.171:6380> SLAVEOF 10.220.5.171 6379
OK
- 将6381的主设置为6379
[root@171 ~]# redis-cli -h 10.220.5.171 -p 6381
10.220.5.171:6381> SLAVEOF 10.220.5.171 6379
OK
- 此时在主节点可以看到连接的从节点
10.220.5.171:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=10.220.5.171,port=6380,state=online,offset=308,lag=1
slave1:ip=10.220.5.171,port=6381,state=online,offset=308,lag=1
- 测试一下主从是否正常
# 主节点写入数据
10.220.5.171:6379> set name xiaoming
OK
# 从节点查看是否有数据
10.220.5.171:6380> get name
"xiaoming"
10.220.5.171:6381> get name
"xiaoming"
第三步：配置监控节点
这里我启用一个sentinel做节点监控
- 创建目录
[root@171 ~]# mkdir /redis/sentinel
[root@171 ~]# cp /etc/redis-sentinel.conf /redis/sentinel/
[root@171 ~]# chown redis.redis /redis/sentinel/ -R
- 修改配置文件
[root@171 ~]# vim /redis/sentinel/redis-sentinel.conf
sentinel monitor mymaster 10.220.5.171 6379 1
sentinel down-after-milliseconds mymaster 3000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
protected-mode no
daemonize yes
- 启动sentinel
[root@171 ~]# redis-sentinel /redis/sentinel/redis-sentinel.conf
[root@171 ~]# ss -tnl |grep 26379
LISTEN 0 128 *:26379 *:*
LISTEN 0 128 :::26379 :::*
- 连入sentinel查看master的状态
[root@171 ~]# redis-cli -h 10.220.5.171 -p 26379
10.220.5.171:26379> sentinel masters
1) 1) "name"
2) "mymaster"
3) "ip"
4) "10.220.5.171"
5) "port"
6) "6379"
7) "runid"
8) "e8deacd44d2f3d99a005a110f6600cebd42c9a5f"
9) "flags"
10) "master"
# 也可以查看一下mymaster这个节点的从节点有哪些
10.220.5.171:26379> sentinel slaves mymaster
第四步：模拟主节点故障
这里我直接关闭主节点服务来模拟主节点宕机
[root@171 ~]# ps aux |grep 6379
root 1810 0.6 0.9 147356 9764 ? Ssl 03:50 0:13 redis-server 10.220.5.171:6379
[root@171 ~]# kill -9 1810
# 稍等一分钟，查看一下此时的主节点
10.220.5.171:26379> sentinel masters
1) 1) "name"
2) "mymaster"
3) "ip"
4) "10.220.5.171"
5) "port"
6) "6381" <<<<<<已经主节点变成了6381
7) "runid"
注意：即使故障节点恢复了，也不会直接变为主节点而是会成为从节点。
到这里redis的主从复制高可用就大功告成了，如有疑问欢迎评论留言，公共探讨，共同进步。
------做运维之前很矫情的小年轻-----