什么是分布式一致性
首先假设我们服务器系统中只有一个结点（node），这个结点可以是一个数据库服务器存储着单一的值，有一个客户端向这个服务器发送了一个值，这个值可以很容易就满足一致性。但是，如果我们的服务器部署在集群上，有多个结点，每次对这些服务器发起的操作，都需要使他们的结果达成一致，看起来像是一台机器一样，这就是分布式一致性问题。Raft就是一种实现分布式一致性的协议
结点的状态
每个结点可以有三种状态：Follower，Candidate，Leader。所有的结点都是从Follower状态开始的，如果followers没有收到leader的RPC消息，则可以转换为candidate，而candidate需要发起投票，其他结点参与投票，回复他们的投票结果，如果这个candidate获得了大部分的选票，就可以成为leader结点了。这就是Leader Election过程。。
Leader Election
下面来看看选举的具体过程。Raft里有两个管理选举的计时器，第一个选举计时器（election timeout）是记录follower结点变成candidate结点所需要的时间，一般在150ms-300ms之间（随机），在这一轮计时结束后，有的follower结点转换成了candidate结点，就开始了真正的选举，首先candidate结点会投票给自己，然后向其他结点发起投票请求，如果收到消息的结点在这一轮倒计时中没有投出票，默认是投给candidate结点的。一旦一个candidate得到了大部分的选票，就转换成了leader结点。大部分的选票保证了一次选举只会有一个leader结点
然后每个节点重置他们的第二个election timeout（headrbeat timeout）,Follower接收到Leader的心跳包的同时也重置选举定时器这个leader结点开始要做的就是发送AppendEntries消息给他的follower结点。这种消息就像心跳包一样，在固定的间隔时间会发送。Follower结点也会回复每一条AppendEntries消息。这一轮的选举周期会持续直到一个follower结点停止接收心跳包（可能有很多种原因）并成为了candidate结点。
这时就会重新选举（re-election），过程和前面一样。
此外，如果选举的时候有两个或多个结点同时成为candidate结点，则会发生竞选的过程，当然，这个过程和前面过程也一样，直到有candidate结点获得大部分选票才能成为leader结点。
Log Replication
现在，所有的请求都需要先经过leader结点，每一条leader会把它作为一个log entry，添加到节点的日志里，log现在还没有提交，所以不会修改结点的值，而是先给其它的server发AppendEntriesRPC，leader结点会等待直到大部分结点修改了他们的entry，然后log可以被提交了，值也会被修改，然后leader会告诉其他结点entry提交了，其他节点执行相同的操作，这样，所有结点保持了一致性
如果出现了网络分区（network partitions），则会出现两个leader的情况，小分区的nodes的日志不会被提交，因为这个分区的leader得不到大部分nodes的回复（相对于整个系统来说），当解决了分区问题，则这个小分区的nodes都会重新根据大分区leader的日志来保持一致性。