Redis Cluster集群故障转移

1. 故障发现

    1.1 主观下线，Redis集群通过Gossip的ping,pong消息来互相通信，比如A节点向B节点发送ping，如果在 cluster-node-timeout时间内一直失败，则节点A会认为B是主观下线，同时将此状态信息在集群内广播

    1.2 客观下线，当半数以上的持有槽的主节点都标记B是主观下线时，触发客观下线流程。

          1.2.1 通知集群内所有节点，标记B为客观下线并立刻生效

          1.2.2 通知故障节点的从节点触发故障转移

2. 故障恢复

    客观下线后，如果故障节点是持有槽的主节点，需要从它的从节点中选一个替换它，保证集群高可用。当从节点通过内部的定时任务发现主节点客观下线，将会触发故障恢复流程。

    2.1 资格检查，从节点检查最后与主节点断线时间，如果超过一定时间（配置参数），则不具备资格。

    2.2 准备选举时间，会让延迟最小的从节点优先发起选举。

    2.3 发起选举

          2.3.1 更新配置纪元（clusterNode.configEpoch），每个主节点维护一个配置纪元，主节点的配置纪元都不相同，从节点复制主节点的配置纪元，整个集群有维护以全局配置纪元用于记录所有的最大版本。从节点每次投票都会自增全局的配置纪元并单独保存，用于标示自己发起选举的版本

          2.3.2 向集群发送消息，保证该从节点在一个配置纪元只发送一次消息

    2.4 选举投票

          只有持有槽的主节点才会处理故障选举，投票过程是领导者选举过程，每个配置纪元内每个节点只有一张选票，因此只能有一个从节点获得N/2+1的选票，当超过一定时间没有从节点选出会选举作废开始下一轮选举。

    2.5 替换主节点

           当从节点获取足够的票后，触发替换主节点，将当前节点变为主节点，讲主节点负责的槽委派给自己，然后广播自己的pong消息，通知所有节点自己变为主节点