## 说明 * **故障节点从主观下线变为客观下线后，如果下线节点是持有槽的主节点则需要在它的从节点中选出一个替换它，从而保证集群的高可用**。下线主节点的所有从节点承担故障恢复的义务，当从节点通过内部定时任务发现自身复制的主节点进入客观下线时，将会触发故障恢复流程，如下图所示：  ## 资格检查 * 每个从节点都要检查最后与主节点断线时间，判断是否有资格替换故障的主节点; * 如果从节点与主节点断线时间**超过cluster-node-time\*cluster-slavevalidity-factor，(默认是15秒)**则当前从节点不具备故障转移资格**。参数cluster-slavevalidity-factor用于从节点的有效因子，默认为10(10*15 = 150); 也就是说超过150秒就没有资格成为主节点了; ## 准备选举时间 * 当从节点符合故障转移资格后，**更新触发故障选举的时间，只有到达该时间后才能执行后续流程** * **这里之所以采用延迟触发机制，**主要是通过对多个从节点使用不同的延迟选举时间来支持优先级问题。**复制偏移量越大说明从节点延迟越低，那么它应该具有更高的优先级来替换故障主节点** * **使用之上的优先级排名，更新选举触发时间** * **所有的从节点中复制偏移量最大的将提前触发故障选举流程**  * 主节点b进入客观下线后，**它的三个从节点根据自身复制偏移量设置延迟选举时间，**如复制偏移量最大的节点slave b-1延迟1秒执行，保证复制延迟低的从节点优先发起选举 ## 发起选举 ## 选举投票 * **只有持有槽的主节点才会处理故障选举消息**（FAILOVER\_AUTH\_REQUEST），因为每个持有槽的节点在一个配置纪元内都有唯一的一张选票，当接到第一个请求投票的从节点消息时回复FAILOVER\_AUTH\_ACK消息作为投票，之后相同配置纪元内其他从节点的 选举消息将忽略 * **投票过程其实是一个领导者选举的过程，**如集群内有N个持有槽的主节点代表有N张选票。由于在每个配置纪元内持有槽的主节点只能投票给一个 从节点，因此只能有一个从节点获得N/2+1的选票，保证能够找出唯一的从节点 * **Redis集群没有直接使用从节点进行领导者选举，**主要因为从节点数必须大于等于3个才能保证凑够N/2+1个节点，将导致从节点资源浪费。使用 集群内所有持有槽的主节点进行领导者选举，即使只有一个从节点也可以完 成选举过程 * **当从节点收集到N/2+1个持有槽的主节点投票时，从节点可以执行替换主节点操作**，例如集群内有5个持有槽的主节点，主节点b故障后还有4个， 当其中一个从节点收集到3张投票时代表获得了足够的选票可以进行替换主 节点操作，如下图所示  * * **运维提示：**故障主节点也算在投票数内，假设集群内节点规模是3主3从，其中有2 个主节点部署在一台机器上，当这台机器宕机时，由于从节点无法收集到3/2+1个主节点选票将导致故障转移失败。这个问题也适用于故障发现环 节。**因此部署集群时所有主节点最少需要部署在3台物理机上才能避免单点问题** * **投票作废：**每个配置纪元代表了一次选举周期，如果在开始投票之后的cluster-node-timeout\*2时间内从节点没有获取足够数量的投票，则本次选举作废。从节点对配置纪元自增并发起下一轮投票，直到选举成功为止 ## 替换主节点 **当从节点收集到足够的选票之后，触发替换主节点操作：** * 1）当前从节点**取消复制变为主节点** * 2）执行clusterDelSlot操作**撤销故障主节点负责的槽**，并执行clusterAddSlot把这些槽委派给自己 * **3）向集群广播自己的pong消息，**通知集群内所有的节点当前从节点变为主节点并接管了故障主节点的槽信息