5 定时任务
- 每10s 每个 sentinel 对 master 和 replica 执行 INFO 命令
- 发现 replica 节点
- 确认主从关系
- 每 2s 每个 sentinel 通过 master 节点的channel交换信息(pub/sub)
- 通过 sentinel :java频道交互
- 交互对节点的"看法”和自身信息
- 每 1s 每个 sentinel 对其他 sentinel 和 redis 执行ping
- 心跳检测，失败判定依据
6 主观下线、客观下线
6.1 主观下线(Subjectively Down，SDOWN)
单个 Sentinel 节点对服务器做出的下线判断，即单个 Sentinel 认为某个服务下线（有可能是接收不到订阅，之间的网络不通等一系列原因）。
主观下线是每个sentinel节点对Redis节点失败的偏见。
所以还需客观下线机制。
6.2 客观下线(Objectively Down，ODOWN)
多个 Sentinel 实例在对同一服务器做出 SDOWN 判断，并通过命令互相交流后，得出的服务器下线判断，然后开启 failover。
只有在足够数量( 超过quorum个)的 Sentinel 都将一个服务器标记为主观下线后， 服务器才会被标记为客观下线（ODOWN）。
只有当 M 被认定为客观下线时，才会发生故障迁移。
仲裁
仲裁指配置文件中的 quorum 参数。某个 Sentinel 先将 Master 节点标记为主观下线，然后会将这个判定通过 sentinel is-master-down-by-addr 命令询问其他 Sentinel 节点是否也同样认为该 addr 的 Master 节点要做主观下线。
sentinel monitor <masterName> <ip> < port> <quorum> sentinel monitor myMaster 127.0.0.1 6379 2 # sentinel down-after-milliseconds < masterName> < timeout> sentinel down-after-milliseconds mymaster 30000
最后当达成这一共识的 Sentinel 个数达到前面说的 quorum 设置的值时，该 Master 节点会被认定为客观下线并进行故障转移。
quorum 值一般设为 Sentinel 个数的二分之一加 1，例如 3 个 Sentinel 就设为 2。
综上可得
哨兵工作原理
- 每个 Sentinel 以 1次/s 向它所知的 Master，Slave 以及其他 Sentinel 节点发送一个 PING
- 若一个实例距离最后一次有效回复 PING 的时间超过配置文件
down-after-milliseconds，则该实例会被 Sentinel 标记为 主观下线 - 若一个 Master 被标记为主观下线，则正在监视该 Master 的所有 Sentinel 会 1次/s 确认 Master 是否真的进入主观下线状态
- 当有足够数量 Sentinel（大于等于配置文件指定的值）在指定时间范围内确认 Master 的确进入主观下线状态，则 Master 会被标记为 客观下线
- 若 Master 处于 ODOWN 状态，则投票自动选出新Master。将剩余从节点指向新Master继续数据复制
- 在正常情况下，每个 Sentinel 会以每 10 秒一次的频率向它已知的所有 Master，Slave 发送 INFO 命令；当 Master 被 Sentinel 标记为客观下线时，Sentinel 向已下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次（因为原来是稳定的，10s 一次info就是为了看看有没有新加入的 sentinel，但现在故障了，所以要尽快将环境稳定好，快速确认完主从关系）
- 若没有足够数量 Sentinel 同意 Master 已经下线，Master 的客观下线状态会被移除。若 Master 重新向 Sentinel 的 PING 命令返回有效回复，Master 的主观下线状态就会被移除。
7 领导者选举
原因：只有一个sentinel节点完成故障转移。
选举：通过sentinel is-master-down-by-addr命令都希望成为领导者：
- 每个做主观下线的Sentinel节点向其他Sentinel节点发送命令，要求将它设置为领导者
- 收到命令的Sentinel节点如果没有同意通过其他Sentinel节点发送的命令，那么将同意该请求，否则拒绝
- 如果该Sentinel节点发现自己的票数已经超过Sentinel集合半数且超过quorum，则将成为领导者
- 如果此过程有多个Sentinel节点成为了领导者，那么将等待一段时间重新选举
- 选举实例
8 故障转移
领导者节点完成
- 从slave节点中选出一个“合适的"节点作为新的master节点
- 对上面的slave节点执行slaveof no one命令让其成为master节点
- 向剩余slave节点发送命令，让它们成为新master节点的slave节点，复制规则和parallel-syncs参数有关
- 更新对原来master节点配置为slave，并保持着对其关注，当其恢复后命令它去复制新的master节点。
选择合适的slave节点
- 选择slave priority(slave节点优先级)最高的slave节点，如果存在划返同，不存在则继续。
- 选择复制偏移量最大的slave节点(复制的最完整)，若存在则返回，不存在则
继续。 - 选择runId最小的slave节点。
常见开发运维问题
节点运维
- 机器下线:例如过保等情况
- 机器性能不足:例如CPU、内存、硬盘、网络等
- 节点自身故障:例如服务不稳定等
主节点
sentinel failover <masterName>
节点下线
- 从节点:临时下线还是永久下线,例如是否做一些清理工作。但是要考虑读写分离的情况。
- Sentinel节点: 同上。
节点上线
- 主节点: sentinel failover进行替换
- 从节点: slaveof即可, sentinel节点可以感知
- sentinel节点:参考其他sentinel节点启动即可。
从节点的作用
- 副本：高可用基础
- 拓展读能力
由于Redis Sentinel只会对主节点进行故障转移,对从节点采取主观的下线,所以需要自定义一个客户端来监控对应的事件
三个消息
- +switch-master :切换主节点(从节点晋升主节点)
- +convert-to-slave :切换从节点(原主节点降为从节点)
- +sdown:主观下线。
总结
- Redis Sentinel是Redis的高可用实现方案：
故障发现、故障自动转移、配置中心、客户端通知。 - Redis Sentinel从2.8版本开始才正式生产可用
- 尽可能在不同物理机上部署Redis Sentinel的所有节点
- Redis Sentinel中的Sentinel节点个数应该≥3，且最好为奇数，便于选举
- Redis Sentinel中的数据节点与普通数据节点无差异
- 客户端初始化时连接的是Sentinel节点集合，不再是具体的Redis节点，但
Sentinel只是配置中心，并非代理 - Redis Sentinel通过三个定时任务实现了Sentinel节点对于主节点、从节点、
其余Sentinel节点的监控 - Redis Sentinel在对节点做失败判定时分为主观下线和客观下线
- 看懂Redis Sentinel故障转移日志对于Redis Sentinel以及问题排查非常有帮助
- Redis Sentinel实现读写分离高可用可以依赖Sentinel节点的消息通知,获取Redis数据节点的状态变化
参考
