redis集群模式工作原理（三）

本篇博客聊聊redis集群如何实现故障转移的？也就是集群的高可用性的。
主节点会有自己的从节点，他的从节点保存在 clusterNode的 slaves属性中。那么在集群中是如何发现主节点下线，以及从节点如何被选举为主节点，接替已经下线的主节点的呢？
首先，在集群中集群中的每个节点都会向其他节点发送ping消息，来确定彼此的存在。如果一个节点向（源节点）另一个节点（目标节点）发送ping消息，但是在规定的时间内没有收到响应的pong消息，那么源节点就会把目标节点标记为疑似下线状态（PFAIL）
另外，集群中的1节点还会相互发送消息交换集群中各个节点自身的状态信息。比如某个节点是否处于在线状态，还是疑似在线状态，或者已经下线。
比如说，当主节点node1通过消息得知主节点node2认为node3进入了疑似下线状态，主节点A会在自己的clusterNode结构中nodes字典找到节点node3对应的结构，并且会将主节点node2的疑似下线报告添加到疑似下线节点也就是node3的clusterNode的fail_reports链表中。
一个集群中如果半数以上的主节点都将主节点node标记为疑似下线状态，那么node将要被标记为下线状态，将node标记为下线状态的主节点会将node节点下线的消息广播给集群中的其他节点，所有收到这条消息的节点都会将ndoe标记为下线状态。
那么怎样故障转移呢？
当一个从节点发现自己正在复制的主节点处于下线状态时，他会发起一次选举。
1）这个从节点会向集群中其他节点广播一条CLUSTER_TYPE_FAILOVER_AUTH_REQUEST消息，要求所有收到这条消息的，并且具有投票权的主节点投票给这个从节点。
2）主节点在收到这条选举消息时，他会比较自己的纪元是否和从节点的纪元相等，如果相等则投票给这个从节点，也就是回复CLUSTER_TYPE_FAILOVER_AUTH_ACK,并把自己的纪元加1
3)每个从节点都会都会计算自己的所得的投票数，是否大于等于n/2+1,如果是，自己胜出。选举结束
4）如果不是，继续下一轮的选举。
胜出的从节点会进行故障转移操作，他要做以下几件事情。
1）执行slave of no one命令，成为主节点
2）撤销对下线主节点的槽指派，并把这些槽指派给自己。
3）向集群中的其他节点广播一条pong消息，这样集群中的其他节点就会知道该从节点已经升级为主节点，并且他已经接管了由原来已下线主节点所负责的槽
4）新的主节点开始接收和自己负责的槽相关的命令，至此，故障转移完成。