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