Redis.6 故障转移
Redis 集群自身实现了高可用。高可用首先需要解决集群部分失败的场景：当集群内少量节点出现故障时通过自动故障转移保证集群可以正常对外提供服务
Redis.6.1 故障发现
当集群内某个节点出现问题时，需要通过一种健壮的方式保证识别出节点是否
发生了故障。Redis 集群内节点通过 ping/pong 消息实现节点通信，消息不但可以传播节点槽信息，还可以传播其他状态如：主从状态、节点故障等。因此故障发现也是通过消息传播机制实现的，主要环节包括：主观下线（pfail）和客观下线（fail）。
·主观下线：指某个节点认为另一个节点不可用，即下线状态，这个状态并不是最终的故障判定，只能代表一个节点的意见，可能存在误判情况。
·客观下线：指标记一个节点真正的下线，集群内多个节点都认为该节点不可
用，从而达成共识的结果。如果是持有槽的主节点故障，需要为该节点进行故
障转移。
- 主观下线
- 集群中每个节点都会定期向其他节点发送 ping 消息，接收节点回复 pong 消息
- 作为响应。如果在 cluster-node-timeout 时间内通信一直失败，则发送节点会
- 认为接收节点存在故障，把接收节点标记为主观下线（pfail）状态。流程如图所示。
流程说明：
1）节点 a 发送 ping 消息给节点 b，如果通信正常将接收到 pong 消息，节点 a更新最近一次与节点 b 的通信时间。
2）如果节点 a 与节点 b 通信出现问题则断开连接，下次会进行重连。如果一直通信失败，则节点 a 记录的与节点 b 最后通信时间将无法更新。
3）节点 a 内的定时任务检测到与节点 b 最后通信时间超高 cluster-nodetimeout 时，更新本地对节点 b 的状态为主观下线（pfail）。
主观下线简单来讲就是，当 cluster-note-timeout 时间内某节点无法与另一个节点顺利完成 ping 消息通信时，则将该节点标记为主观下线状态。每个节点内的cluster State 结构都需要保存其他节点信息，用于从自身视角判断其他节点的状态。
2.客观下线
当某个节点判断另一个节点主观下线后，相应的节点状态会跟随消息在集群内
传播。ping/pong 消息的消息体会携带集群 1/10 的其他节点状态数据，当接受节点发现消息体中含有主观下线的节点状态时，会在本地找到故障节点的
ClusterNode 结构，保存到下线报告链表中。
流程说明：
1）当消息体内含有其他节点的 pfail 状态会判断发送节点的状态，如果发送节点是主节点则对报告的 pfail 状态处理，从节点则忽略。
2）找到 pfail 对应的节点结构，更新 clusterNode 内部下线报告链表。
3）根据更新后的下线报告链表告尝试进行客观下线。
