缓存框架——Redis的哨兵机制

1. 哨兵任务

• 监控(Monitoring)：哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。
• 提醒(Notification)：当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
• 自动故障迁移(Automatic failover)：当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master。

2. 哨兵的定时监控任务

2.1 任务1

每个哨兵节点每10秒会向主节点和从节点发送info命令获取最拓扑结构图，哨兵配置时只要配置对主节点的监控即可，通过向主节点发送info，获取从节点的信息，并当有新的从节点加入时可以马上感知到

2.2 任务2

每个哨兵节点每隔2秒会向redis数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其它哨兵节点的信息及对主节点的判断，其实就是通过消息publish和subscribe来完成的

2.3 任务3

每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据

3. 主观下线和客观下线

3.1 主观下线

刚知道哨兵节点每隔1秒对主节点和从节点、其它哨兵节点发送ping做心跳检测，当这些心跳检测时间超过down-after-milliseconds时，哨兵节点则认为该节点错误或下线，这叫主观下线；这可能会存在错误的判断。

3.2 客观下线

当主观下线的节点是主节点时，此时该哨兵3节点会通过指令sentinel is-masterdown-by-addr寻求其它哨兵节点对主节点的判断，当超过quorum（法定人数）个数，此时哨兵节点则认为该主节点确实有问题，这样就客观下线了，大部分哨兵节点都同意下线操作，也就说是客观下线

3.3 领导者哨兵选举流程

• 每个在线的哨兵节点都可以成为领导者，当它确认（比如哨兵3）主节点下线时，会向其它哨兵发is-master-down-by-addr命令，征求判断并要求将自己设置为领导者，由领导者处理故障转移；
• 当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；
• 如果哨兵3发现自己在选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举…………

4. 故障转移机制

4.1 由Sentinel节点定期监控发现主节点是否出现了故障

sentinel会向master发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了

4.2 当主节点出现故障，此时3个Sentinel节点共同选举了Sentinel3节点为领导，负载处理主节点的故障转移

4.3 由Sentinel3领导者节点执行故障转移，过程和主从复制一样，但是自动执行

流程：

• 将slave-1脱离原从节点，升级主节点，

• 将从节点slave-2指向新的主节点

• 通知客户端主节点已更换

• 将原主节点（oldMaster）变成从节点，指向新的主节点

4.4 故障转移后的redis sentinel的拓扑结构图

哨兵机制－故障转移详细流程

• 过滤掉不健康的（下线或断线），没有回复过哨兵ping响应的从节点
• 选择salve-priority从节点优先级最高（redis.conf）
• 选择复制偏移量最大，指复制最完整的从节点

参考链接：https://blog.csdn.net/baihualindesu/article/details/89953049