Paxos与Raft的简明比较

1

基本术语和操作对应

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

你可能感兴趣的

载入中...