分布式一致性协议Raft-案例剖析

前言

这是Raft系列文章的第二篇。在上一篇《认识Raft》 中我们成功论证了Raft保证集群数据一致性的问题。然而现实世界是非常复杂的，任何情况都可能发生。那么对于各种异常场景Raft集群究竟如何应对的呢？

本篇会列举几个经典的Case来解释Raft的应对措施。如果没看过上一篇《认识Raft》 文章的同学可以先看一下，这篇相当于上篇的加强补充篇。

案例剖析

场景一-选票瓜分

上一篇我们知道，Leader为了巩固自己的领导地位，会定期向Follower发送心跳。假设集群中有4个节点，当Leader挂掉的时候，如果Follower有多个都出现心跳超时，这时集群会出现多个Candidate进行选举。
上图展示节点B和节点C同时成为Candidate，并且分别向其他三个节点发送投票请求（绿色小球表示投票请求）。因为B和C首先都会投给自己一票，要想成为Leader，还需要至少两个节点投票给自己形成多数派。Raft规定：每个节点对同一个Term最多投一票。 此时B和C都处于Term 4，而A和D处于Term 3，因此B