Redis的哨兵模式

  在⼀个典型的哨兵模式下，⾄少需要3 个哨兵实例来避免 “ 脑裂 ” （⽹络分裂导致多个主服务器同时存在）。哨兵们会通过投票来决定主服务器是否已经下线，以及选择哪个从服务器升级为新的主服务器。

        哨兵模式的实现是基于发布 - 订阅模式的，每个哨兵节点都会订阅其它哨兵节点的信息，这样当主服务器出现故障时，哨兵节点可以及时进⾏⼴播，实现快速故障转移。

Sentinel （哨兵）时基于⼼跳机制检测服务状态的，每隔 1 秒向每隔实例发送⼀个ping命令，如果某个 sentinel 发现某 Redis 实例未在规定时间内响应，则认为该实例 主观下线 ，若超过指定数量（ quorum ）的 sentinel 都认为该实例 主观下线 ，则该实例客观下线 。 quorum 的值最好超过 Sentinel 实例数的⼀半

1. 如果此时主服务器宕机，哨兵1检测到了，系统并不会⽴即进⾏failover（故障转移）过程
2. 此时仅仅是哨兵1主管的认为主服务不可⽤，此现象为主观下线
3. 当后续的哨兵也检测到主服务器不可⽤时，并且数量达指定数量时
4. 哨兵之间就会进⾏⼀次投票，投票结果由1个哨兵发起，进⾏failover操作
5. 切换成功之后，就会通过发布订阅模式，让各个哨兵把⾃⼰监控的从服务器切换主机，这个过程为客观下线

哨兵模式的选举过程：

1. ⾸先会判断slave节点与master节点断开时间⻓短，如果超过指定值 (down-after-milliseconds*10)则会排除该slave节点
2. 然后判断slave节点的slave-priority值，越⼩优先级越⾼，如果是0则永不参与选举
3. 如果slave-prority⼀样，则判断slave节点的offset值，越⼤说明数据越新，优先级越⾼
4. 最后是判断slave节点的运⾏id⼤⼩，越⼩优先级越⾼

故障转移过程：

1. Sentinel给备选的节点发送slaveof on one命令，让该节点成为Maskter
2. Sentinel给其他slave发送 “slaveof ip 端⼝” 命令，开始从Master上同步数据
3. 最后Sentinel将故障节点标记为slave（执⾏slaveof ip 端⼝命令），故障节点恢复以后也会成为新Master的slave