实现原理

本节将介绍Redis Sentinel的基本实现原理，具体包含以下几个方面：Redis Sentinel的三个定时任务、主观下线和客观下线、Sentinel领导者选举、故障转移，相信通过本节的徐诶读者能对Redis Sentinel的高可用特性有更加深入的理解和认识。

1. 三个定时监控任务

   一套合理的监控机制是Sentinel节点判定节点不可达的重要保证，Redis Sentinel通过三个定时监控任务完成对各个节点发现和监控：

   1）每个10秒，每个Sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构。例如下面就是在一个主节点上执行info replication的结果片段：

   # Replication
   role:master
   connected_slaves:2
   slave0:ip=127.0.0.1,port=6380,state=online,offset=4917,lag=1
   slave1:ip=127.0.0.1,port=6381,state=online,offset=4917,lag=1
   

   Sentinel节点通过对上述结果进行解析就可以找到对应的从节点。

   这个定时任务的作用具体可以表现在三个方面：

   • 通过向主节点执行info命令，获取从节点的信息，这也是为什么Sentinel节点不需要显式配置监控从节点。

   • 当有新的从节点加入时都可以立刻感知出来。

   • 节点不可达或者故障转移后，可以通过info命令实时更新节点拓扑信息。

   2）每隔2秒，每隔Sentinel节点会向Redis数据节点的sentinel:hello频道上发送该Sentinle节点对于主节点的判断以及当前Sentinel节点的信息，同时每隔Sentinel节点也会订阅该频道，来了解其他Sentinel节点以及它们对主节点的判断，所以这个定时任务可以完成以下两个工作：

   • 发现新的Sentinel节点：通过订阅主节点sentinel:hello了解其他Sentinel节点信息，如果是新加入的Sentinel节点，将该Sentinel节点信息保存起来，并与该Sentinel节点创建连接。

   • Sentinel节点之间交换主节点的状态，作为后面客观下线以及领导者选举的依据。Sentinel节点publish的消息格式如下：

   <Sentinel节点IP> <Sentinel节点端口> <Sentinel节点runId> <Sentinel节点配置版本> <主节点名字> <主节点IP> <主节点端口> <主节点配置版本>
   

   3）每个1秒，每个Sentinel节点会向主节点、从节点、其余Sentinel节点发送一条ping命令做一次心跳检测，来确认这些节点当前是否可达。通过定时任务，Sentinel节点对主节点、从节点、其余Sentinel节点都建立起连接，实现了对每个节点的监控，这个定时任务是节点失败判定的重要依据。

2. 主观下线和客观下线

   1. 主观下线

      上一小节介绍的第三个定时任务，每个Sentinel节点会每隔1秒对主节点、从节点、其他Sentinel节点发送ping命令做心跳检测，当这些节点超过down-after-milliseconds没有进行有效回复，Sentinel节点就会对该节点做失败判定，这个行为叫主观下线。从字面意思也可以很容易看出主观下线是当前Sentinel节点的一家之言，存在误判的可能。

   2. 客观下线

      当Sentinel主观下线的节点是主节点时，该Sentinel节点会通过sentinel is-master-down-by-addr命令向其他Sentinel节点询问对主节点的判断，当超过< quorum >个数，Sentinel节点认为主节点确实有问题，这时该Sentinel节点会做出客观下线的决定，这样客观下线的含义比较明显了，也就是大部分Sentinel节点都对主节点的下线做了同意的判定，那么这个判定就是客观的。

   注意：从节点、Sentinel在主观下线后，没有后续的故障转移操作。

   这里有必要对sentinel is-master-down-by-addr命令做一个介绍，它的使用方法如下：

   sentinel is-master-down-by-addr <ip> <port> <current_epoch> <runid>

   • ip：主节点IP。
   • port：主节点端口。
   • current_epoch：当前配置纪元。
   • runid：此参数有两种类型，不同类型决定了此API作用的不同。

   当runid等于“*”是，作用是Sentinel节点直接交换对主节点下线的判定。

   当runid等于当前Sentinel节点的runid时，作用是当前Sentinel希望目标Sentinel节点同意自己成为领导者的请求，有关Sentinel领导者选举，后面会进行介绍。

   该命令返回结果包含三个参数，如下所示：

   • down_state：目标Sentinel节点对于主节点的下线判断，1是下线，0是在线。

   • leader_runid：当leader_rundi等于“*”时，代表返回结果是用来做主节点是否不可达，当leader_rundi等于具体的runid，代表目标节点同意rundi成为领导者。

   • leader_epoch：领导者纪元。

3. 领导者Sentinel节点选举

   假如Sentinel节点对于主节点已经做了客观下线，那么是不是就可以立即进行故障转移了？当然不是，实际上故障转移的工作只需要一个Sentinel节点来完成即可，所以Sentinel节点之间会做一个领导者选举的工作，选出一个Sentinel节点作为领导者进行故障转移的工作。Redis使用了Raft算法实现领导者选举，因为Raft算法相对比较抽象和复杂，以及篇幅所限，所以这里给出一个Redis Sentinel进行领导者选举的大致思路：

   1）每个在线的Sentinel节点都有资格成为领导者，当它确认主节点主观下线时候，会向其他Sentinel节点发送sentinel is-master-down-by-addr命令，要求将自己设置为领导者。

   2）收到命令的Sentinel节点，如果没有同意过其他Sentinel节点sentinel is-master-down-by-addr命令，将同意该请求，否则拒绝。

   3）如果该Sentinel节点发现自己的票数已经大于等于max(quorum, num(sentinels)/2 + 1)，那么它将成为领导者。

   4）如果此过程没有选举出领导者，将进入下一次选举。

4. 故障转移

   领导者选举出的Sentinel节点负责故障转移，具体步骤如下：

   1）在通节点列表中选出一个节点作为新的主节点，选择方法如下：

    a）过滤：“不健康”（主观下线、断线）、5秒内没有回复过Sentinel节点ping响应、与主节点失联超过down-after-milliseconds*10秒。
   
    b）选择slave-priority（从节点优先级）最高的从节点列表，如果存在则返回，不存在则继续。
   
    c）选择复制偏移量最大的从节点（复制的最完整），如果存在则返回，不存在则继续。
   
    d）选择runid最小的从节点。
   

   2）Sentinel领导者节点会对第一步选出来的从节点执行slaveof no one命令让其成为主节点。

   3）Sentinel领导者节点会向剩余的从节点发送命令，让它们成为新主节点的从节点，复制规则和parallel-syncs参数有关。

   4）Sentinel节点集合会将原来的主节点更新为从节点，并保持这对其关注，当其恢复后命令它去复制新的主节点。