【Redis哨兵机制原理】

三个定时任务

Sentinel 维护着三个定时任务以监测 Redis 节点及其它 Sentinel 节点的状态。
（1 ） info 任务
每个 Sentinel 节点每 10 秒就会向 Redis 集群中的每个节点发送 info 命令，以获得最新的Redis 拓扑结构。
（2 ） 心跳任务
每个Sentinel节点每1秒就会向所有Redis节点及其它Sentinel节点发送一条ping命令，
以检测这些节点的存活状态。该任务是判断节点在线状态的重要依据。
（3 ） 发布/ 订阅任务
每个 Sentinel 节点在启动时都会向所有 Redis 节点订阅_ sentinel :hello 主题的信息，当 Redis 节点中该主题的信息发生了变化，就会立即通知到所有订阅者。
启动后，每个 Sentinel 节点每 2 秒就会向每个 Redis 节点发布一条 sentinel :hello 主题的信息，该信息是当前 Sentinel 对每个 Redis 节点在线状态的判断结果及当前 Sentinel 节点信息。
当 Sentinel 节点接收到 sentinel _:hello 主题信息后，就会读取并解析这些信息，然后
主要完成以下三项工作：

• 如果发现有新的 Sentinel 节点加入，则记录下新加入 Sentinel 节点信息，并与其建立连接。
• 如果发现有 Sentinel Leader 选举的选票信息，则执行 Leader 选举过程。
• 汇总其它 Sentinel 节点对当前 Redis 节点在线状态的判断结果，作为 Redis 节点客观下线的判断依据。

Redis 节点下线判断

对于每个 Redis 节点在线状态的监控是由 Sentinel 完成的。
（1 ） 主观下线
每个 Sentinel 节点每秒就会向每个 Redis 节点发送 ping 心跳检测，如果 Sentinel 在
down-after-milliseconds 时间内没有收到某 Redis 节点的回复，则 Sentinel 节点就会对该 Redis节点做出“下线状态”的判断。这个判断仅仅是当前 Sentinel 节点的“一家之言”，所以称为主观下线。
（2 ） 客观下线
当 Sentinel 主观下线的节点是 master 时，该 Sentinel 节点会向每个其它 Sentinel 节点发送 sentinel is-master-down-by-addr 命令，以询问其对 master 在线状态的判断结果。这些Sentinel 节点在收到命令后会向这个发问 Sentinel 节点响应 0（在线）或 1（下线）。当 Sentinel收到超过 quorum 个下线判断后，就会对 master 做出客观下线判断

Sentinel Leader 选举

当Sentinel节点对master做出客观下线判断后会由Sentinel Leader来完成后续的故障转
移，即 Sentinel 集群中的节点也并非是对等节点，是存在 Leader 与 Follower 的。
Sentinel 集群的 Leader 选举是通过 Raft 算法实现的。Raft 算法比较复杂，后面会详细学习。这里仅简单介绍一下大致思路。
每个选举参与者都具有当选 Leader 的资格，当其完成了“客观下线”判断后，就会立
即“毛遂自荐”推选自己做 Leader，然后将自己的提案发送给所有参与者。其它参与者在收到提案后，只要自己手中的选票没有投出去，其就会立即通过该提案并将同意结果反馈给提案者，后续再过来的提案会由于该参与者没有了选票而被拒绝。当提案者收到了同意反馈数量大于等于 max(quorum，sentinelNum/2+1)时，该提案者当选 Leader。
说明：

• 在网络没有问题的前提下，基本就是谁先做出了“客观下线”判断，谁就会首先发起
  Sentinel Leader 的选举，谁就会得到大多数参与者的支持，谁就会当选 Leader。
• Sentinel Leader 选举会在次故障转移发生之前进行。
• 故障转移结束后 Sentinel 不再维护这种 Leader-Follower 关系，即 Leader 不再存在。

master 选择算法

在进行故障转移时，Sentinel Leader需要从所有Redis的Slave节点中选择出新Master。
其选择算法为：

1. 过滤掉所有主观下线的，或心跳没有响应 Sentinel 的，或 replica-priority 值为 0 的 Redis节点
2. 在剩余 Redis 节点中选择出 replica-priority 最小的的节点列表。如果只有一个节点，则直接返回，否则，继续
3. 从优先级相同的节点列表中选择复制偏移量最大的节点。如果只有一个节点，则直接返回，否则，继续
4. 从复制偏移值量相同的节点列表中选择动态 ID 最小的节点返回

故障转移过程

Sentinel Leader 负责整个故障转移过程，经历了如上步骤：

1. Sentinel Leader 根据 master 选择算法选择出一个 slave 节点作为新的 master
2. Sentinel Leader 向新 master 节点发送 slaveof no one 指令，使其晋升为 master
3. Sentinel Leader 向新 master 发送 info replication 指令，获取到 master 的动态 ID
4. Sentinel Leader 向其余 Redis 节点发送消息，以告知它们新 master 的动态 ID
5. Sentinel Leader 向其余 Redis 节点发送 slaveof 指令，使它们成为新master 的 slave
6. Sentinel Leader 从所有 slave 节点中每次选择出 parallel-syncs 个 slave 从新 master 同步数据，直至所有 slave 全部同步完毕
7. 故障转移完毕