Redis 4：哨兵机制(sentinel)的高可用

1. 高可用

• 当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。
  

2. 三个定时监控任务作用

• 其实整个过程只需要一个哨兵节点来完成，首先使用 Raft 算法（选举算法）实现选举机制，选出一个哨兵节点来完成转移和通知。
• 哨兵有三个定时监控任务完成对各节点的发现和监控：
• 任务 1，每个哨兵节点每 10 秒会向主节点和从节点发送 info 命令获取最拓扑结构图，哨 兵配置时只要配置对主节点的监控即可，通过向主节点发送 info，获取从节点的信息，并当 有新的从节点加入时可以马上感知到；
  
• 任务 2，每个哨兵节点每隔 2 秒会向 redis 数据节点的指定频道上发送该哨兵节点对于主 节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其它哨兵 节点的信息及对主节点的判断，其实就是通过消息 publish 和 subscribe 来完成的；
  
• 任务 3，每隔 1 秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次 ping 命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据。

3. 主观下线

• 因为哨兵节点每隔 1 秒对主节点和从节点、其它哨兵节点发送 ping 做心跳检测，所以当这些心跳检测时间超过 down-after-milliseconds 时，哨兵节点则认为该节点错误或下线，这叫主观下线；这可能会存在错误的判断。因为这个检测结果不一定准确，所以不会做故障转移。
  

4. 客观下线

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

5. 领导者哨兵选举流程

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

6. 故障转移

1. 由 Sentinel 节点定期监控发现主节点是否出现了故障
   sentinel 会向 master 发送心跳 PING 来确认 master 是否存活，如果 master 在“一定 时间范围”内不回应 PONG 或者是回复了一个错误消息，那么这个 sentinel 会主观地(单方面地)认为这个 master 已经不可用了
   
2. 当主节点出现故障，此时假设3个Sentinel节点共同选举了Sentinel3节点为领导者sentinel，负载处理主节点的故障转移
   
3. 由Sentinel3领导者节点执行故障转移，过程和主从复制一样，但是自动执行
   
   流程： 1、将 slave-1 脱离原从节点，升级主节点， 2、将从节点 slave-2 指向新的主节点 3、通知客户端主节点已更换 4、将原主节点（oldMaster）变成从节点，指向新的主节点

• 故障转移后的 redis sentinel 的拓扑结构图
  
• 故障转移详细流程