Quorum与Paxos，Raft等一致性协议有什么区别，这个问题的答案本身很简单：一致性协议大多使用了Quorum机制，但仅仅有Quorum(R+W>N)机制是保证不了一致性的。本文计划延伸这个问题，以Raft为例回答一个完善的一致性协议拥有包括Quorum在内的那些机制，试着说明这些机制的完备以及其中每一项的不可或缺。
要回答这个问题首先需要说明Raft是做什么的，Paxos、Raft被称为一致性协议，顾名思义它们要解决的是多节点的一致性问题，需要注意的是这里所说的一致性并不是要求所有节点在任何时刻状态完全一致。而是要保证：
即使发生网络分区或机器节点异常，整个集群依然能够像单机一样提供一致的服务，即在每次操作时都可以看到其之前的所有成功操作按顺序完成。
这里有两点需要说明：
强调在网络分区或节点异常时，是因为如果不考虑这种异常状况，一致性是非常容易保证的，单节点即可。而一致性协议所要做的就是在容忍异常的情况下保证一致。
这里的一致是对集群外部使用者而言的，将整个集群看做一个整体。
将每一个对Raft集群的操作称为一个提案，希望Raft集群对外屏蔽内部的网络或节点异常，依次对每一个提案作出相应，提交成功的提案可以在后续操作中持续可见。这里的提案需要是幂等的，即重复执行不会导致集群状态不同。
接下来我们就看Raft是如何实现这种一致性保证的。Raft将一致性问题拆分为三个子问题，各个击破，从而使得其实现简单易懂。本文将首先简单介绍其三个子问题的内容以及达成方式；之后证明三个子问题是实现一致性的充分条件；最后尝试说明这三个子问题的保证缺一不可。
1. Leader Election
组成一个Raft集群至少需要三台机器，而Raft限制每一时刻最多只能有一个节点可以发起提案，这个限制极大的简化了一致性的实现，这个可以发起提案的节点称为Leader。因此所要解决的第一个问题便是：
如何保证任何时候最多只有一个Leader节点
以及当Leader节点异常时如何尽快的选择出新的Leader节点。 
如上图所示： 所有的节点以Follower的角色启动； Leader周期性给其他节点发送心跳； 在超时时间内没有收到心跳包的Follower变成Candidate，将自己的Term加一，并广播Vote请求，发起新一轮选举； 选举结束： 收到大多数节点的投票，变成Leader，并向其他节点发送自己Term的AppendEntry。在一个Term里，同一个Server只会给出一次投票，先到先得； 收到相同或更大Term的AppendEntry，承认对方为Leader，变成Follower； 超时，重新开始新的选举，通过随机的超时时间来减少这种情况得发生。 从上面对Raft状态转换的讨论中可以看到，任何非Leader的节点都有可能在未来成为Leader，为了能保证后续Leader节点变化后依然能够使得整个集群对外保持一致，需要通过Log Replication机制来解决如下两个问题： Follower以与Leader节点相同的顺序依次执行每个成功提案; 每个成功提交的提案必须有足够多的成功副本，来保证后续的访问一致 上图描述了一个Raft提案的执行过程： Leader收到Client的请求，写入本地Log，之后并行地向所有Follower通过AppendEntry请求发送该Log Entry； Follower对收到的Entry进行验证，包括验证其之前的一条Log Entry项是不是和Leader相同，验证成功后写入本地Log并返回Leader成功； Leader收到超过半数的Follower答复成功后，将当前Log Commit（如写入状态机），之后返回客户端成功； 后续的AppendEntry及HeartBeat都会携带主的Commit位置，Follower会提交该位置之前的所有Log Entry。
2. Log Replication
