哨兵机制的基本流程
哨兵是一个运行在特殊模式下的Redis进程，主从库实例运行时，他也在运行。
哨兵负责三个任务：监控，*选主*（选择主库）和通知。
监控
监控是指哨兵进程运行时，周期性给所有主从库发送PING命令，检测他们是否仍然在线运行。
从库没有在规定时间内响应哨兵的PING命令，哨兵就会把它标记为"下线状态"；
主库没有在规定时间呢响应哨兵的PING命令，哨兵就会判定主库下线启动选主流程。
选主
哨兵在主库挂了以后，按照一定规则从从库中选出作为新的主库。
哨兵机制(sentinel)的高可用
原理： 当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。
其实整个过程只需要一个哨兵节点来完成，首先使用Raft算法（选举算法）实现选举机制，选出一个哨兵节点来完成转移和通知
3.哨兵的定时监控任务
任务1： 每个哨兵节点每10秒会向主节点和从节点发送info命令获取最拓扑结构图，哨兵配置时只要配置对主节点的监控即可，通过向主节点发送info，获取从节点的信息，并当有新的从节点加入时可以马上感知到。
任务2： 每个哨兵节点每隔2秒会向redis数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其它哨兵节点的信息及对主节点的判断，其实就是通过消息publish和subscribe来完成的。
任务3： 每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据。
客观下线： 当主观下线的节点是主节点时，此时该哨兵3节点会通过指令sentinel is-masterdown-by-addr寻求其它哨兵节点对主节点的判断，当超过quorum（选举）个数，此时哨兵节点则认为该主节点确实有问题，这样就客观下线了，大部分哨兵节点都同意下线操作，也就说是客观下线。
领导者哨兵选举流程
-
每个在线的哨兵节点都可以成为领导者，当它确认（比如哨兵3）主节点下线时，会向其它哨兵发is-master-down-by-addr命令，征求判断并要求将自己设置为领导者，由领导者处理故障转移；
-
当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；
-
如果哨兵3发现自己在选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举…………
故障转移机制
由Sentinel节点定期监控发现主节点是否出现了故障： sentinel会向master发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了
当主节点出现故障， 此时3个Sentinel节点共同选举了Sentinel3节点为领导，负载处理主节点的故障转移
由Sentinel3领导者节点执行故障转移，过程和主从复制一样，但是自动执行
流程：
- 将slave-1脱离原从节点，升级主节点，(从库打分)
- 将从节点slave-2指向新的主节点
- 通知客户端主节点已更换
- 将原主节点（oldMaster）变成从节点，指向新的主节点
故障转移详细流程-确认主节点：
按照三个规则依次进行三轮打分，这三个规则分别是****从库优先级*，从库复制进度和从库ID号**。只要在某一轮中从库得分最高，他就是主库了。选主过程结束。如果没***有出现得分最高**的从库，那就会继续进行下一轮**。
第一轮：优先级最高的从库得分高
通过配置slave-priority配置项，给不同从库设置不同优先级。比如两个从库内存大小不一样，可以手动设置内存大的实例设置为一个高优先级。选主时候哨兵会选出优先级最高的打高分作为新主库，如果得分一直，那就开始第二轮打分。
第二轮：和旧主库同步程度最接近的从库得分高
如果选择与旧主库同步最接近的从库作为主库，那么新主库上就有最新的数据。
如何判断从库和旧主库间的同步进度？
从库的slave_repl_offset最接近旧主库的master_repl_offset，那么它的得分最高，可以作为新主库。
如果两个从库的slave_repl_offset值大小一样，那么就需要进入第三轮打分了。
第三轮：ID号越小得分越高
每个实例在创建时候都会有一个ID，目前Redsi在选主从库时，有一个默认的规定：在优先级和复制进度都相同的情况下，ID号最小的从库得分最高，会被选为新主库。选主完成！
故障转移后的redis sentinel的拓扑结构图
总结
redis哨兵的作用:
- 监控主数据库和从数据库是否正常运行。
- 主数据库出现故障时，可以自动将从数据库转换为主数据库，实现自动切换。
评论区