版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/jingzi123456789/article/details/83716493
目录
本博文主要总结关于哨兵的一些理论知识，主要关注点有一下几个方面：
一、哨兵解决了什么问题？
二、哨兵是如何解决“问题一”的？
三、如何使用哨兵？
四、Redis Sentinel客户端实现的原理是什么？Java如何操作Redis Sentinel？
三、如何使用哨兵？
3.1、哨兵环境部署
在Redis哨兵原理总结（一）中介绍了使用哨兵为我们解决了什么问题，在Redis哨兵原理总结（二）总结了哨兵是如何执行监控、主节点故障转移的。
关于如何搭建部署Redis哨兵环境，网络上有很多博客，下面筛选了几篇：
3、基于Sentinel（哨兵）搭建实现Redis高可用集群
3.2、主节点、从节点、哨兵节点配置文件解释
3.2.1、主节点redis.conf文件解释
port 6379
daemonize yes
logfile "/opt/RedisServer/log/matser.log"
dbfilename "dump-6379.rdb"
dir "opt/RedisServer/data"3.2.2、从节点redis.conf文件解释
port 6380
daemonize yes
logfile "/opt/RedisServer/log/slave-6380.log"
dbfilename "dump-6380.rdb"
dir "opt/RedisServer/data"
slaveof 127.0.0.1 63793.2.3、哨兵节点sentinel.conf文件解释
# 哨兵sentinel实例运行的端口，默认26379
port 26379
# 哨兵sentinel的工作目录
dir "/opt/Home/bin"
# 哨兵日志
logfile "/var/log/redis/sentinel.log"
# 哨兵sentinel监控的redis主节点的
## ip：主机ip地址
## port：哨兵端口号
## master-name：可以自己命名的主节点名字（只能由字母A-z、数字0-9 、这三个字符".-_"组成。）
## quorum：当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2
# 当在Redis实例中开启了requirepass <foobared>，所有连接Redis实例的客户端都要提供密码。
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster 123456
# 指定主节点应答哨兵sentinel的ping命令心跳检测最大时间间隔，超过这个时间，哨兵主观上认为主节点下线，默认30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000
# 指定了在发生failover主备切换时，最多可以有多少个slave同时对新的master进行同步。这个数字越小，完成failover所需的时间就越长；反之，但是如果这个数字越大，就意味着越多的slave因为replication而不可用。可以通过将这个值设为1，来保证每次只有一个slave，处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
# 故障转移的超时时间failover-timeout，默认三分钟，可以用在以下这些方面：
## 1. 同一个sentinel对同一个master两次failover之间的间隔时间。
## 2. 当一个slave从一个错误的master那里同步数据时开始，直到slave被纠正为从正确的master那里同步数据时结束。
## 3. 当想要取消一个正在进行的failover时所需要的时间。
## 4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来同步数据了
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000
# 当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本。一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。
# 对于脚本的运行结果有以下规则：
## 1. 若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10。
## 2. 若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
## 3. 如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
# sentinel notification-script <master-name> <script-path>
sentinel notification-script mymaster /var/redis/notify.sh
# 这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh3.3、哨兵节点日志分析
下面以 Redis Sentinel（哨兵）部署 这篇文中测试的结果进行哨兵节点日志解释与分析：
192.168.1.51:7000 主
192.168.1.52:7000 从
192.168.1.53:7000 从
注意：在日志@符号后面的就是master的name，ip，port。在主从切换成功后，51就变成了52。
3273:X 08 Apr 10:58:08.285 * Increased maximum number of open files to 10032 (it was originally set to 1024).
_._
_.-``__ ''-._
_.-`` `. `_. ''-._ Redis 3.2.8 (00000000/0) 64 bit
.-`` .-```. ```\/ _.,_ ''-._
( ' , .-` | `, ) Running in sentinel mode
|`-._`-...-` __...-.``-._|'` _.-'| Port: 27000
| `-._ `._ / _.-' | PID: 29948
`-._ `-._ `-./ _.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' | http://redis.io
`-._ `-._`-.__.-'_.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' |
`-._ `-._`-.__.-'_.-' _.-'
`-._ `-.__.-' _.-'
`-._ _.-'
`-.__.-'
3273:X 08 Apr 10:58:08.286 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
【哨兵192.168.1.51:27000的ID号】
3273:X 08 Apr 10:58:08.286 # Sentinel ID is 725b3bc06f18e8db913a44bbbdbc23a3be54c4d1
【哨兵监控的master是192.168.1.51:7000，quorum=2表示判断主节点失败至少需要两个sentinel节点同意】
3273:X 08 Apr 10:58:08.286 # +monitor master pmaster 192.168.1.51 7000 quorum 2
【哨兵主观和客观判断master下线】
3273:X 08 Apr 10:58:08.330 # +sdown master redis-master 192.168.1.51 7000
【多个哨兵客观判断master下线，2/2:反斜线前面的2是配置在sentinel.conf文件配置判断主节点不可达的所需要的票数，
后面的2是有2哨兵主观投票主节点不可达。】
3273:X 08 Apr 10:58:08.385 # +odown master redis-master 192.168.1.51 7000 #quorum 2/2
【该哨兵更新自己的配置纪元。纪元的作用：】
3273:X 08 Apr 10:58:08.385 # +new-epoch 1
【一个新的故障迁移操作正在执行中，开始选择负责主从切换的leader，等待被大多数 Sentinel 选中,
选出来的leader负责故障转移工作】
3273:X 08 Apr 10:58:08.385 # +try-failover master redis-master 192.168.1.51 7000
【哨兵投票选择此ID的一个哨兵负责主从切换的leader哨兵，投票给了自己】
3273:X 08 Apr 10:58:08.388 # +vote-for-leader 725b3bc06f18e8db913a44bbbdbc23a3be54c4d1 1
【52,53都投了51哨兵作为leader】
3273:X 08 Apr 10:58:08.392 # 192.168.1.52:27000 voted for 725b3bc06f18e8db913a44bbbdbc23a3be54c4d1 1
3273:X 08 Apr 10:58:08.393 # 192.168.1.53:27000 voted for 725b3bc06f18e8db913a44bbbdbc23a3be54c4d1 1
【当前哨兵被选择为主从切换的leader】
3273:X 08 Apr 10:58:08.489 # +elected-leader master redis-master 192.168.1.51 7000
【开始选择一个合适的从节点成为新的主节点，代替192.168.1.51:7000】
3273:X 08 Apr 10:58:08.489 # +failover-state-select-slave master redis-master 192.168.1.51 7000
【选择了一个slave节点：192.168.1.52:7000将作为新的主节点】
3273:X 08 Apr 10:58:08.580 # +selected-slave slave 192.168.1.52:7000 192.168.1.52 7000 @ redis-master 192.168.1.51 7000
【命令192.168.1.52:7000从节点执行slaveof no one，使其成为主节点】
3273:X 08 Apr 10:58:08.580 * +failover-state-send-slaveof-noone slave 192.168.1.52:7000 192.168.1.52 7000 @ redis-master 192.168.1.51 7000
【等待192.168.1.52:7000节点晋升成为主节点】
3273:X 08 Apr 10:58:08.633 * +failover-state-wait-promotion slave 192.168.1.52:7000 192.168.1.52 7000 @ redis-master 192.168.1.51 7000
【确认192.168.1.52:7000节点晋升成为主节点】
3273:X 08 Apr 10:58:09.561 # +promoted-slave slave 192.168.1.52:7000 192.168.1.52 7000 @ redis-master 192.168.1.51 7000
【172.16.0.34:6379节点晋升成为主节点】
3273:X 08 Apr 10:58:09.561 # +failover-state-reconf-slaves master redis-master 192.168.1.51 7000
【命令192.168.1.53:7000节点复制新的主节点192.168.1.52:7000】
3273:X 08 Apr 10:58:09.612 * +slave-reconf-sent slave 192.168.1.53:7000 192.168.1.53 7000 @ redis-master 192.168.1.51 7000
3273:X 08 Apr 10:58:10.517 # -odown master redis-master 192.168.1.51 7000
【192.168.1.52:7000节点正在重新配置成为192.168.1.52:7000节点的从节点，但是同步过程尚未完成】
3273:X 08 Apr 10:58:10.576 * +slave-reconf-inprog slave 192.168.1.53:7000 192.168.1.53 7000 @ redis-master 192.168.1.51 7000
【节点192.168.1.53:7000完成了对节点192.168.1.52:7000的同步】
3273:X 08 Apr 10:58:10.576 * +slave-reconf-done slave 192.168.1.53:7000 192.168.1.53 7000 @ redis-master 192.168.1.51 7000
【故障转移顺利完成】
3273:X 08 Apr 10:58:10.643 # +failover-end master redis-master 192.168.1.51 7000
【故障转移完成后，发布主从节点切换的消息，192.168.1.52:7000成为了新的主节点】
【客户端可订阅+switch-master该频道，来获取新的主节点，这就是为什么主从切换了，
客户端好像觉得没有什么事发生一样，实际上客户端连接的Redis服务器的地址已经变为新的主节点的地址了。】
3273:X 08 Apr 10:58:10.643 # +switch-master redis-master 192.168.1.51 7000 192.168.1.52 7000
【将192.168.1.53:7000关联到192.168.1.52:7000，作为52的从节点】
3273:X 08 Apr 10:58:10.643 * +slave slave 192.168.1.53:7000 192.168.1.53 7000 @ redis-master 192.168.1.52 7000
【将192.168.1.51:7000关联到192.168.1.52:7000，作为52的从节点】
3273:X 08 Apr 10:58:10.643 * +slave slave 192.168.1.51:7000 192.168.1.51 7000 @ redis-master 192.168.1.52 7000
【但是，发现51不能ping通，主观判断51下线】
3273:X 08 Apr 10:58:15.654 # +sdown slave 192.168.1.51:7000 192.168.1.51 7000 @ redis-master 192.168.1.52 7000
【原master节点恢复上线】
原master恢复上线了，该哨兵节点撤销对192.168.1.51:7000下线的主观决定。只要哨兵一开始就监控的这个matser，所有哨兵就会插销这条决定。
3273:X 08 Apr 11:23:10.236 # -sdown slave 192.168.1.51 7000 192.168.1.51 7000 @ redis-master 192.168.1.52 7000
原master192.168.1.51:7000成为了新的master192.168.1.52:7000的slave节点，哨兵更新节点配置：
3273:X 08 Apr 10:58:10.236 * +convert-to-slave slave 192.168.1.51 7000 192.168.1.51 7000 @ redis-master 192.168.1.52 7000下一篇：Redis哨兵原理总结（四）将分析Java连接哨兵的源码，以及分析主从切换后是如何实现对客户端无感知的。