什么是Redis哨兵

监控后台的预警者负责持续检查主服务器（master主机）的运行状态。一旦发现主服务器出现故障，系统将启动一个自动化的切换机制。这个机制会根据预设的投票规则，从多个备用服务器（从库）中选择一个来接替主服务器的角色。被选中的备用服务器将升级为新的主服务器，并继续无缝地对外提供服务，确保整个系统的持续稳定运行。这种机制有效避免了单点故障带来的风险，并提升了系统的整体可靠性和容错能力。

Redis哨兵作用

主从状态监测：监控主从redis库运行是否正常

哨兵系统负责不断检测Redis主服务器及其从服务器的运行状态，确保它们都正常运行。
通过实时的心跳检测和状态检查，哨兵能够迅速发现任何主从节点的问题。

消息通知：哨兵可以将故障转移的结果发送给客户端

在发生主服务器故障转移等重要事件时，哨兵有能力向连接的客户端发送通知。
客户端可以接收到这些事件通知，并据此更新其连接配置或执行其他必要的操作。

自动故障恢复：如果master异常，则会进行主从切换，将其中一个slave作为新master

一旦检测到主服务器出现异常，哨兵系统会立即启动故障恢复流程。
这个过程涉及将从服务器中的一个提升为新的主服务器，同时更新其他从服务器的配置，使它们跟随新的主服务器。

动态配置服务：客户端通过连接哨兵来获得当前Redis服务的主节点地址

哨兵系统充当了动态配置服务的角色，客户端无需预先知道主服务器的固定地址。
客户端可以通过与哨兵系统的交互，动态获取当前Redis服务的主服务器地址，确保始终连接到正确的节点。

sentinel配置说明

3台哨兵：自动监控和维护集群，不存放数据，只是吹哨人
1主2从：用于数据读取和存放

操作步骤

在原来的redis目录下新建或拷贝sentinel.conf文件。
重要参数项说明

bind：服务监听地址，用于客户端连接，默认本机地址
daemonize：是否以后台daemon方式运行
protected-model：安全保护模式
port：端口
logfile：日志文件路径
pidfile：pid文件路径
dir：工作目录
sentinel monitor 设置要监控的master服务器
quorum :表示最少有几个哨兵认可客观下线，同意故障迁移的法定票数
网络是不可靠的有时候一个sentinel会因为网络堵塞而误以为master redis已经死掉，在sentinel集群环境下需要多个sentinel互相沟通来确认某个master是否真的死掉了，quorum这个参数是进行客观下线的一个依据，意思是至少有quorum个sentinel认为这个master有故障，才会对这个master进行下线以及故障转移。因为有的时候，某个sentinel节点可能因为自身网络原因，导致无法连接master，而此时master并没有出现故障，所以，这就需要多个sentinel都一致认为改master有问题，才可以进行下一步操作，这就保证了公平性和高可用。
sentinel auth -pass :master设置了密码，连接master服务的密码
sentinel down-after-milliseconds 指定多少毫秒之后，主节点没有应答哨兵，此时哨兵主观上认为主节点下线
sentinel parallel-syncs 表示允许并行同步的slave个数，当Master挂了后，哨兵会选出新的Master，此时，剩余的slave会向新的master发起同步数据
sentinel failover-timeout 故障转移的超时时间，进行故障转移时，如果超过设置的毫秒，表示故障转移失败
sentinel notification-script 配置当某一事件发生时所需要执行的脚本
sentinel client-reconfig-script 客户端重新配置主节点参数脚本

sentinel通用配置及主从复制

sentinel26379.conf、sentinel26380.conf、sentinel26381.conf

先启动一主二从3个redis实例，测试正常的主从复制

主机6379配置修改
6379后续可能会变成从机，需要设置访问新主机的密码，所以此处会设置masterauth，不然后续可能会报错 master_link_status:down
3台不同的虚拟机实例，启动三台真是机器实例并连接
redis-server redis6379.conf

redis-server redis6380.conf

redis-server redis6381.conf

redis-cli -a 123456 -p 6379

redis-cli -a 123456 -p 6380

redis-cli -a 123456 -p 6381

sentinel的两种启动方式
再启动3个哨兵监控后再测试一次主从复制
redis-server sentinel26379.conf –sentinel

redis-server sentinel26380.conf –sentinel

redis-server sentinel26381.conf –sentinel

启动后我们会发现sentinel配置文件会自动在配置文件中加上部分配置

哨兵监控节点异常情况

模拟master主机掉线

手动关闭master6379服务器
问题：

两台从机数据是否还在

slave从机的数据依然存在

是否会从剩下的2台机器上选出新的master

哨兵会通过投票从slave从机里面选出新的master主机

之前掉线的master机器重启回来，谁将会是新老大？会不会双master冲突

本案例中从机6381选举成立新的master,
6379从原先的master降级成了从机slave
6380还是从机，只不过换了一个新的老大master(从6379变成6381)；

更换了master后的6379和6381配置文件变化

老master的redis6379.conf文件

新master的redis6381.conf文件
replicaof 192.168.111.184 6381 slave升级成master，配置文件消失了。

结论

文件的内容会被动态的修改，具体为主从关系的修改。

哨兵运行和选举新master是如何进行的？

当一个主从配置中master失效后，sentinel可以选举出一个新的master用于自动接替原master的工作，主从配置中的其他redis服务器自动指向新的master同步数据，一般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致误切换

运行流程，故障切换

三个哨兵监控一主二从，正常运行中
SDown主观下线(Subjectively Down)

SDOWN（主观不可用）是单个sentinel自己主观上检测到的关于master的状态，从sentinel的角度来看，如果发送了PING心跳后，在一定时间内没有收到合法的回复，就达到了SDOWN的条件。
sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度

选举出领导者哨兵

当主节点被判断客观下线后，各个哨兵节点会进行协商，先选举出一个领导者哨兵节点（兵王）并由该领导者也即被选举出的兵王进行failover（故障转移）。
哨兵领导者，兵王如何选出来的？-> Raft算法

监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法;Raft算法的基本思路是先到先得:即在一轮选举中，哨兵A向B发送成为领导者的申请、如果B没有同意过其他哨兵，则会同意A成为领导者。

由兵王开始推动故障切换流程并选出新的master

新主登基
- 某个slave选为新的master
- 选出新master的规则，剩余Slave节点健康前提下，会按下图规则进行选举
  - redis.conf文件中，优先级slave-priority或者replica-priority最高的从节点(数字越小优先级越高)
  - 复制偏移位置offset最大的从节点(也就是在master还没有宕机时，复制到数据比其他Slave要多)
  - 最小Run ID的从节点，字典顺序，ASCII码
群臣俯首
- 执行slaveof no one命令让选出来的从节点成为新的主节点，并通过slaveof命令让其他节点成为其从节点
- sentinel leader会对选举出的新master执行slaveof on one操作，将其提升为master节点
- sentinel leader向其他slave发送命令，让剩余的slave成为新的master节点的slave
旧主拜服
- 老master重新上线后，会将它设置为新选出的master的从节点
- sentinel leader会让原来的master降级为slave并恢复正常工作