Paxos与Raft的简明比较

基本术语和操做对应

Paxos术语/操做	Raft术语/操做	备注
Proposal Number (PN)	Term	Paxos建议每一个 Proposer 可用的 PN 集合不相交(disjoint sets); Raft 容许各个 Follower 竞选 Leader 时用相同的Term，Voter结合Term和VotedFor，区分到底支持了谁。
Value is Chosen (值被选定/造成决议)	Commit	下面有解释，两者独立性不一样
实例(Paxos Instance)	Log Entry	一系列ID递增的Instance对应一系列Log Entry
Phase 2	AppendEntry	AppendEntry是对前面一个Entry有依赖的

主要过程比较

比较项	基于Paxos的RSM	Raft State Machine
一个实例造成决议的必要条件	接受该提议 Acceptor 造成多数派；	1) 直接 Commit: Term 等于currentTer m的log entry，造成多数派； 2) 间接Commit: 在新 Leader 当选后，对于非当前 Term 的Entry，造成多数派不表明表示已经 Commit。而是经过一个直接 commit，让更早的 entry 被间接 commit (一次性Commit了 commitIndex 及以前全部的 entry)。
各个实例的决议过程，是否独立？	独立，无顺序关系。	有顺序依赖关系： 1) Accept 时的前向依赖：Follower 接受 entry 时，须要按照 PrevLogIndex 和 PrevLogTerm 匹配。2) Commit 时的后向依赖：leader 当选后，直到有 currentTerm 的 log 被 commit,才会让其当选前未 commit 的 entry 变为committed。
Leader 选举	1）必须有过半的 Voter 接受其PN(Term)；2）竞选 Leader 时，PN 大的当选; 3）每一个提议者可以使用的 PN 集合不相交。	1) 必须有过半的 Voter 接受其 PN(Term)；2) 竞选 Leader 时，PN/Term 大的当选; 3) 容许不一样的 Proposer 在竞选 Leader 时用相同的 Term； 4) Leader 的 log 不能比其余 Voter的log旧(经过比较 Term 和 Log 长度);
Leader 当选后如何处理当选以前还没有造成决议的实例？	使用本身的新 PN，对全部未造成决议的实例执行phase 1( Follower 不须要对每一个实例都回复，只须要将那些已经执行到 Phase 2的实例的 Value 返回便可)。而后使用最大的 value 或者 no-op 进行 phase 2，以尽快解决空洞问题。	Leader 采用推送的方式，将本身已经持久化的 log 推送出去。推送的 log 的 term 不变。只有本身当选后发起的 AppendEntry，才会用新Term。
Leader刚当选后执行的Phase 1	Leader选举过程当中的log新旧比较	更换Leader都须要代价的，可是付出代价的时机有差别。
无 Leader 如何运行？	仍然能保证单个实例的 Consensus	无法进行读写
持久化的值	MaxAccepted PN、各个 LogEntry	currentTerm、 VotedFor(与 currentTerm对应)、 各个Log Entry