Redis高可用的原因(三) -- 哨兵机制

在Redis主从模式中 , 如果没有哨兵机制 , 当主节点挂了之后 , 需要程序猿手工去重新选取主节点 , 通知其他从节点归属于新的主节点 , 将旧的主节点设置为从节点归属于新的主节点 … 在手工维护期间 , 就无法提供服务 , 大大降低了程序的可用性 , 因此 , Redis提供了哨兵(sentinel)机制来自动实现上述步骤

1. 哨兵的作用

1. 监控 : sentinel会通过心跳机制不断检查master和slave是否正常工作
2. 故障恢复 : 当master节点发生故障时 , sentinel会选择一个slave节点作为新的master 节点 , 当故障节点恢复后也以新的master为主节点
3. 通知 : 当redis集群发生故障后 , sentinel会将最新的master信息推送给redis集群

2. 怎么判断一个节点下线

• 主观下线 : 如果某个sentinel节点发现实例没有在规定时间内响应 , 那么就认为该节点主观下线
• 客观下线 : 如果超过指定数量(quorum)的sentinel节点在规定时间内都没有收到实例的响应 , 那么就认为该节点客观下线 , quorum最好超过sentinel节点数量的一半

Redis节点客观下线才是真正下线 .

3. 怎么选择新的主节点

一旦发现master故障，sentinel需要在salve中选择一个作为新的master，选择依据是这样的：

• 首先会判断slave节点与master节点断开时间长短，如果超过指定值（down-after-milliseconds * 10）则会排除该slave节点
• 然后判断slave节点的slave-priority值，越小优先级越高，如果是0则永不参与选举
• 如果slave-prority一样，则判断slave节点的offset值，越大说明数据越新，优先级越高

4. 故障转移步骤

• sentinel节点会选出leader , 由这个节点去进行故障恢复
• 选中的leader sentinel会选择出新的master节点 , 并让该节点执行slaveof no one命令 , 该节点成为新的master节点
• sentinel给其他节点发送slaveof 新的master节点命令 , 让这些节点成为新的master节点的从节点
• 最后标记故障节点为slave节点 , 当该节点重启后 , 也自动以新的master节点为主节点