Redis高可用Sentinel哨兵
前言：
Sentinel哨兵是redis官方提供的高可用方案，可以用它来监控多个Redis服务实例的运行情况。Redis Sentinel 是一个运行在特殊模式下的Redis服务器。Redis Sentinel是在多个Sentinel进程环境下互相协作工作的。
Sentinel系统有三个主要任务：
1.监控：Sentinel不断的检查主服务和从服务器是否按照预期正常工作。
2.提醒：被监控的Redis出现问题时，Sentinel会通知管理员或其他应用程序。
3.自动故障转移：监控的主Redis不能正常工作，Sentinel会开始进行故障迁移操作。将一个从服务器升级新的主服务器。 让其他从服务器挂到新的主服务器。同时向客户端提供新的主服务器地址。
修改sentinel.conf配置文件
1、修改133redis的sentinel.conf配置文件
2、vim sentinel.conf
3、格式：sentinel monitor <name> <masterIP> <masterPort> <Quorum投票数>
4、Sentinel监控主(Master)Redis, Sentinel根据Master的配置自动发现Master的Slave,Sentinel默认端口号为26379 。
5、135,136的sentinel.conf 配置文件和133一样
3.启动Sentinel
-
启动一个运行在Sentinel模式下的Redis服务实例
-
./redis-sentinel sentinel配置文件
-
启动133，135,136
-
133日志信息
5.135日志信息
6.136日志信息
7.停止133主redis
8.133sentinel日志信息
9.135sentinel日志信息
10.136sentinel日志信息
11.登录135查看主从关系
12.重新启动133,133sentinel日志信息
13.135sentienl日志信息
14.136sentienl日志信息，把136转换为135的从
15.登录136查看主从关系，133加入成功
至此sentinel高可用搭建完成，主从关系为：135主，133,136从，重新启动也是这样的关系，因为它去修改了redis.conf配置文件中配置的主从关系，自己看一下redis.conf配置文件就可以了
报错
5586:S 20 Feb 12:13:51.068 * Connecting to MASTER 192.168.184.133:6379
5586:S 20 Feb 12:13:51.068 * MASTER <-> SLAVE sync started
5586:S 20 Feb 12:13:51.069 # Error condition on socket for SYNC: Connection refused
添加该配置就可以解决
protected-mode no #保护模式如果开启只接受回环地址的ipv4和ipv6地址链接，拒绝外部链接，而且正常应该配置多个哨兵，避免一个哨兵出现独裁情况，如果配置多个哨兵那如果开启也会拒绝其他sentinel的连接。导致哨兵配置无法生效。
/////////////////////////////////////////////////////////
sentinel常用配置
port 26379 #端口
daemonize yes #后台启动
protected-mode no #保护模式如果开启只接受回环地址的ipv4和ipv6地址链接，拒绝外部链接，而且正常应该配置多个哨兵，避免一个哨兵出现独裁情况，如果配置多个哨兵那如果开启也会拒绝其他sentinel的连接。导致哨兵配置无法生效。
logfile "/usr/local/redis-3.2.9/log/sentinel.log" #指明日志文件，如果有该配置的话，显示启动控制台也不会显示日志信息，日志信息都在你指定的日志文件中
dir "/data/redis/sentinel"
sentinel monitor mymaster 192.168.184.133 6379 2 #哨兵监控的master。
sentinel down-after-milliseconds mymaster 5000 #master或者slave多少时间（默认30秒）不能使用标记为down状态。
sentinel failover-timeout mymaster 9000 #若哨兵在配置值内未能完成故障转移操作，则任务本次故障转移失败。
sentinel auth-pass mymaster redispass #如果redis配置了密码，那这里必须配置认证，否则不能自动切换
监控
Sentinel会不断检查Master和Slave是否正常
如果Sentinel挂了，就无法监控，所以需要多个哨兵，组成Sentinel网络，一个健康的Sentinel至少有3个Sentinel应用。 彼此在独立的物理机器或虚拟机。
监控同一个Master的Sentinel会自动连接，组成一个分布式的Sentinel网络，互相通信并交换彼此关于被监控服务器的信息
当一个Sentinel认为被监控的服务器已经下线时，它会向网络中的其它Sentinel进行确认，判断该服务器是否真的已经下线
如果下线的服务器为主服务器，那么Sentinel网络将对下线主服务器进行自动故障转移，通过将下线主服务器的某个从服务器提升为新的主服务器，并让其从服务器转移到新的主服务器下，以此来让系统重新回到正常状态
下线的旧主服务器重新上线，Sentinel会让它成为从，挂到新的主服务器下
总结
主从复制，解决了读请求的分担，从节点下线，会使得读请求能力有所下降，Master下线，写请求无法执行
Sentinel会在Master下线后自动执行故障转移操作，提升一台Slave为Master，并让其它Slave成为新Master的Slave
原文链接：https://blog.csdn.net/qq_39669058/java/article/details/87777196
