redis 6.2 故障恢复
当故障节点被标记为客观下线时，如果该节点是持有槽的主节点，则需要从其从节点中选出一个进行替换，以确保集群的高可用性。所有从节点都负责故障恢复，当从节点通过内部定时任务发现其所复制的主要节点进入客观下线状态时，将触发故障恢复流程。
-
资格检查
每个从节点需要检查最后与主节点断线的时间，以判断是否有资格替换故障的主节点。如果从节点与主节点断线时间超过
cluster-node-timeout * cluster-slave-validity-factor，则该从节点不具备故障转移资格。参数cluster-slave-validity-factor是从节点的有效因子，默认值为 10。 -
准备选举时间
当从节点符合故障转移资格后，会更新触发故障选举的时间，只有在达到该时间后才能进行后续流程。以下是与故障选举时间相关的字段：
struct clusterState { ... mstime_t failover_auth_time; /* 记录之前或者下次将要执行故障选举时间 */ int failover_auth_rank; /* 记录当前从节点排名 */ }采用延迟触发机制主要是通过对多个从节点设置不同的延迟选举时间来支持优先级问题。（具体伪代码请参见相关文档）
-
发起选举
当从节点定时任务检测到达到故障选举时间（
failover_auth_time）时，会发起选举流程如下：（1）更新配置纪元
配置纪元是一个只增不减的整数，每个主节点自身维护一个配置纪元（`clusterNode.configEpoch`）以标示当前主节点的版本，所有主节点的配置纪元都不相同，从节点会复制主节点的配置纪元。
配置纪元的应用场景包括：
- 新节点加入。
- 槽节点映射冲突检测。
- 从节点投票选举冲突检测。
（2）广播选举消息
在集群内广播选举消息（
FAILOVER_AUTH_REQUEST），并记录已发送消息的状态，确保该从节点在一个配置纪元内只能发起一次选举。消息内容类似于 ping 消息，只是将 type 类型更改为FAILOVER_AUTH_REQUEST。 -
选举投票
只有持有槽的主节点会处理故障选举消息（
FAILOVER_AUTH_REQUEST），因为每个持有槽的节点在一个配置纪元内都拥有一张唯一选票。投票过程实际上是一个领导者选举的过程，如集群内有 N 个持有槽的主节点，代表有 N 张选票。由于在每个配置纪元内持有槽的主节点只能投票给一个从节点，因此只能有一个从节点获得 N/2+1 的选票，从而保证能够找出唯一的从节点。
例如，集群内有 5 个持有槽的主节点，当主节点 b 故障后还有 4 个，当其中一个从节点收集到 3 张投票时，代表已获得足够的选票可以进行替换主节点操作，故障主节点也算在投票数内。假设集群内节点规模是 3 主 3 从，其中有 2 个主节点部署在一台机器上，当这台机器宕机时，由于从节点无法收集到 3/2+1 个主节点选票，将导致故障转移失败。这个问题也适用于故障发现环节。
因此，在部署集群时，所有主节点至少需要部署在 3 台物理机上才能避免单点问题。
