Redis的哨兵模式
什么是哨兵模式
Redis的哨兵模式（ Sentinel mode ）是⼀个⾼可⽤解决⽅案，当运⾏多个 Redis 实例并且需要⾃动故障转移时，哨兵模式⾮常有⽤。
在⼀个典型的哨兵模式下，⾄少需要3 个哨兵实例来避免 “ 脑裂 ” （⽹络分裂导致多个主服务器同时存在）。哨兵们会通过投票来决定主服务器是否已经下线，以及选择哪个从服务器升级为新的主服务器。
哨兵模式的实现是基于发布 - 订阅模式的，每个哨兵节点都会订阅其它哨兵节点的信息，这样当主服务器出现故障时，哨兵节点可以及时进⾏⼴播，实现快速故障转移。
哨兵模式主要有三个⽬标：
- 监控：哨兵模式会不断地检查主服务器和从服务器是否按预期⼯作。
- 通知：如果某些Redis实例有故障，哨兵模式可以通过API向管理员或者其他应⽤程序发送通知。
- ⾃动故障转移：如果主服务器⽆法正常⼯作，哨兵模式可以开始⼀个故障转移过程，由⼀个从服务器升级为新的主服务器，并让其他从服务器改变他们的主服务器为新的主服务器。
哨兵模式的特点：
- 哨兵模式⾃动转移失败的主服务器到⼀个从服务器。
- 哨兵模式持续监控所有Redis服务器，以便在需要时报告错误。
- 通过提供⼀个基于哨兵的API，客户端可以⾃动发现新的主服务器地址。
哨兵模式的判断下线过程：
Sentinel （哨兵）时基于⼼跳机制检测服务状态的，每隔 1 秒向每隔实例发送⼀个ping命令，如果某个 sentinel 发现某 Redis 实例未在规定时间内响应，则认为该实例 主观下线 ，若超过指定数量（ quorum ）的 sentinel 都认为该实例 主观下线 ，则该实例客观下线 。 quorum 的值最好超过 Sentinel 实例数的⼀半
- 如果此时主服务器宕机，哨兵1检测到了，系统并不会⽴即进⾏failover（故障转移）过程
- 此时仅仅是哨兵1主管的认为主服务不可⽤，此现象为主观下线
- 当后续的哨兵也检测到主服务器不可⽤时，并且数量达指定数量时
- 哨兵之间就会进⾏⼀次投票，投票结果由1个哨兵发起，进⾏failover操作
- 切换成功之后，就会通过发布订阅模式，让各个哨兵把⾃⼰监控的从服务器切换主机，这个过程为客观下线
哨兵模式的选举过程：
⼀旦发现 master 故障， sentinel 需要在 salve 中选择⼀个作为新的 master
- ⾸先会判断slave节点与master节点断开时间⻓短，如果超过指定值 (down-after-milliseconds*10)则会排除该slave节点
- 然后判断slave节点的slave-priority值，越⼩优先级越⾼，如果是0则永不参与选举
- 如果slave-prority⼀样，则判断slave节点的offset值，越⼤说明数据越新，优先级越⾼
- 最后是判断slave节点的运⾏id⼤⼩，越⼩优先级越⾼
故障转移过程：
- Sentinel给备选的节点发送slaveof on one命令，让该节点成为Maskter
- Sentinel给其他slave发送 “slaveof ip 端⼝” 命令，开始从Master上同步数据
- 最后Sentinel将故障节点标记为slave（执⾏slaveof ip 端⼝命令），故障节点恢复以后也会成为新Master的slave