序

本文主要講述2PC及3PC，以及Paxos以及Raft協議。

兩類一致性(操作原子性與副本一致性)

• 2PC協議用于保證屬于多個數據分片上的操作的原子性。這些數據分片可能分布在不同的服務器上，2PC協議保證多臺服務器上的操作要么全部成功，要么全部失敗。

• Paxos協議用于保證同一個數據分片的多個副本之間的數據一致性。當這些副本分布到不同的數據中心時，這個需求尤其強烈。

一、2PC（阻塞、數據不一致問題、單點問題）

Two-Phase?Commit，兩階段提交

1、階段一：提交事務請求（投票階段）

（1）事務詢問

協調者向所有的參與者發送事務內容，詢問是否可以執行事務提交操作，并開始等待各參與者的響應

（2）執行事務

各參與者節點執行事務操作，并將Undo和Redo信息計入事務日志中

（3）各參與者向協調者反饋事務詢問的響應

如果參與者成功執行了事務操作，那么就反饋給協調者Yes響應，表示事務可以執行；如果參與者沒有成功執行事務，那么就反饋給協調者No響應，表示事務不可以執行。

2、階段二：執行事務提交（執行階段）

（1）執行事務提交

如果所有參與者的反饋都是Yes響應，那么

• A、發送提交請求

  協調者向所有參與者節點發出Commit請求

• B、事務提交

  參與者接收到Commit請求后，會正式執行事務提交操作，并在完成提交之后釋放在整個事務執行期間占用的事務資源

• C、反饋事務提交結果

  參與者在完成事務提交之后，向協調者發送ACK信息

• D、完成事務

  協調者接收到所有參與者反饋的ACK消息后，完成事務

（2）中斷事務

任何一個參與者反饋了No響應，或者在等待超時之后，協調者尚無法接收到所有參與者的反饋響應，那么就會中斷事務。

• A、發送回滾請求

  協調者向所有參與者節點發出Rollback請求

• B、事務回滾

  參與者接收到rollback請求后，會利用其在階段一中記錄的Undo信息來執行事務回滾操作，并在完成回滾之后釋放整個事務執行期間占用的資源

• C、反饋事務回滾結果

  參與者在完成事務回滾之后，向協調者發送ACK信息

• D、中斷事務

  協調者接收到所有參與者反饋的ACK信息后，完成事務中斷

優缺點

優點：原理簡單、實現方便
缺點：同步阻塞、單點問題、數據不一致、太過保守

• （1）同步阻塞
  同步阻塞會極大地限制分布式系統的性能。在二階段提交的執行過程中，所有參與該事務操作的邏輯都處于阻塞狀態，各個參與者在等待其他參與者響應的過程中，將無法進行其他任何操作。

• （2）單點問題
  一旦協調者出現問題，那么整個二階段提交流程將無法運轉，更為嚴重的是，如果是在階段二中出現問題，那么其他參與者將會一直處于鎖定事務資源的狀態中，無法繼續完成事務操作。

• （3）數據不一致
  在階段二，當協調者向所有參與者發送commit請求之后，發生了局部網絡異?；騾f調者在尚未發完commit請求之前自身發生了崩潰，導致最終只有部分參與者接收到了commit請求，于是這部分參與者執行事務提交，而沒收到commit請求的參與者則無法進行事務提交，于是整個分布式系統出現了數據不一致性現象。

• （4）太過保守
  如果參與者在與協調者通信期間出現故障，協調者只能靠超時機制來判斷是否需要中斷事務，這個策略比較保守，需要更為完善的容錯機制，任意一個節點的失敗都會導致整個事務的失敗。

二、3PC（解決2PC的阻塞，但還是可能造成數據不一致）

Three-Phase Commit，三階段提交，分為CanCommit、PreCommit、do Commit三個階段。

為了避免在通知所有參與者提交事務時，其中一個參與者crash不一致時，就出現了三階段提交的方式。三階段提交在兩階段提交的基礎上增加了一個preCommit的過程，當所有參與者收到preCommit后，并不執行動作，直到收到commit或超過一定時間后才完成操作。

1、階段一CanCommit

• （1）事務詢問
  協調者向各參與者發送CanCommit的請求，詢問是否可以執行事務提交操作，并開始等待各參與者的響應

• （2）參與者向協調者反饋詢問的響應
  參與者收到CanCommit請求后，正常情況下，如果自身認為可以順利執行事務，那么會反饋Yes響應，并進入預備狀態，否則反饋No。

2、階段二PreCommit

（1）執行事務預提交

如果協調者接收到各參與者反饋都是Yes，那么執行事務預提交

• A、發送預提交請求
  協調者向各參與者發送preCommit請求，并進入prepared階段

• B、事務預提交
  參與者接收到preCommit請求后，會執行事務操作，并將Undo和Redo信息記錄到事務日記中

• C、各參與者向協調者反饋事務執行的響應
  如果各參與者都成功執行了事務操作，那么反饋給協調者Ack響應，同時等待最終指令，提交commit或者終止abort

（2）中斷事務

如果任何一個參與者向協調者反饋了No響應，或者在等待超時后，協調者無法接收到所有參與者的反饋，那么就會中斷事務。

• A、發送中斷請求

  協調者向所有參與者發送abort請求

• B、中斷事務

  無論是收到來自協調者的abort請求，還是等待超時，參與者都中斷事務

3、階段三doCommit

（1）執行提交

• A、發送提交請求
  假設協調者正常工作，接收到了所有參與者的ack響應，那么它將從預提交階段進入提交狀態，并向所有參與者發送doCommit請求

• B、事務提交
  參與者收到doCommit請求后，正式提交事務，并在完成事務提交后釋放占用的資源

• C、反饋事務提交結果
  參與者完成事務提交后，向協調者發送ACK信息

• D、完成事務
  協調者接收到所有參與者ack信息，完成事務

（2）中斷事務

假設協調者正常工作，并且有任一參與者反饋No，或者在等待超時后無法接收所有參與者的反饋，都會中斷事務

• A、發送中斷請求
  協調者向所有參與者節點發送abort請求

• B、事務回滾
  參與者接收到abort請求后，利用undo日志執行事務回滾，并在完成事務回滾后釋放占用的資源

• C、反饋事務回滾結果
  參與者在完成事務回滾之后，向協調者發送ack信息

• D、中斷事務
  協調者接收到所有參與者反饋的ack信息后，中斷事務。

階段三可能出現的問題：
協調者出現問題、協調者與參與者之間網絡出現故障。不論出現哪種情況，最終都會導致參與者無法及時接收到來自協調者的doCommit或是abort請求，針對這種情況，參與者都會在等待超時后，繼續進行事務提交（timeout后中斷事務）。

優點：降低參與者阻塞范圍，并能夠在出現單點故障后繼續達成一致
缺點：引入preCommit階段，在這個階段如果出現網絡分區，協調者無法與參與者正常通信，參與者依然會進行事務提交，造成數據不一致。

三、Paxos（解決單點問題）

基于消息傳遞且具有高度容錯性的一致性算法。Paxos算法要解決的問題就是如何在可能發生幾起宕機或網絡異常的分布式系統中，快速且正確地在集群內部對某個數據的值達成一致，并且保證不論發生以上任何異常，都不會破壞整個系統的一致性。

拜占庭問題：消息不完整或者被篡改。Paxos在維持領導者選舉或者變量修改一致性上，采取一種類似議會投票的過半同意機制，比如設定一個領導者，需要將此看做一個議案，征求過半同意，每個節點通過一個議案會有編號記錄，再次收到此領導者的不同人選，發現已經有編號記錄便駁回，最后以多數通過的結果為準。

我們舉個簡單的例子，來闡述一下Paxos的基本思想：假設我們有5臺計算機A、B、C、D、E，每臺計算機保存著公司CEO的信息，現在CEO任期到了，需要進行新一界選舉了。

A計算機發起一個選舉議案，提議CEO為“張三”，如果沒有其他候選人議案，也沒有網絡問題，只要其中半數以上計算機收到并通過議案，那么最終“張三”當選CEO。由于是分布式環境，并發請求、機器故障、網絡故障等問題是常態，如果A和E同時提交選舉議案，A提名“張三”，E提名“李四”，那么肯定會涉及多計算機的一致性問題了：假設A、B、C先收到A的議案，D、E先收到E的議案，那么A繼續提交給D時，D告訴它已經先收到E的議案了，因此駁回了A的請求。同樣E繼續提交給A、B、C時也碰到相同的問題。

我們可以通過“在每臺計算機同時接受議案提交時設置一個編號，編號先的通過，編號后的駁回”的方式來實現。議案提交上去后，發現A、B、C投票“張三”為CEO，D、E投票“李四”為CEO，少數服從多數，因此最后結果為“張三”當選CEO。

如果是C計算機發生了網絡問題或者故障，雙方投票相同，那么選舉無法完成。

如果C計算機發生了網絡問題或者故障，A、B、D投票“張三”，E投票“李四”，那么結果為“張三”當選，而C對于這些情況一無所知，但是當C計算機恢復正常時，他會發起一個“詢問誰是CEO”的議案獲取最新信息。簡言之，Paxos對每個節點的并發修改采取編號記錄的方式保持一致性，對多個節點的并發修改采取少數服從多數的方式保持一致性。Paxos有點類似分布式二階段提交方式，但是又不同，二階段提交不能是多數節點同意，必須是全部同意。為了遵守過半節點同意的約束，Paxos算法往往要求節點總數為奇數。

Paxos 算法解決的問題是在一個可能發生上述異常的分布式系統中如何就某個值達成一致，保證不論發生以上任何異常，都不會破壞決議的一致性。一個典型的場景是，在一個分布式數據庫系統中，如果各節點的初始狀態一致，每個節點都執行相同的操作序列，那么他們最后能得到一個一致的狀態。為保證每個節點執行相同的命令序列，需要在每一條指令上執行一個「一致性算法」以保證每個節點看到的指令一致。一個通用的一致性算法可以應用在許多場景中，是分布式計算中的重要問題。從20世紀80年代起對于一致性算法的研究就沒有停止過。

簡單說來，Paxos的目的是讓整個集群的結點對某個值的變更達成一致。Paxos算法基本上來說是個民主選舉的算法——大多數的決定會成個整個集群的統一決定。任何一個點都可以提出要修改某個數據的提案，是否通過這個提案取決于這個集群中是否有超過半數的結點同意（所以Paxos算法需要集群中的結點是單數）。

這個算法有兩個階段（假設這個有三個結點：A，B，C）：

第一階段：Prepare階段

A把申請修改的請求Prepare Request發給所有的結點A，B，C。注意，Paxos算法會有一個Sequence Number（你可以認為是一個提案號，這個數不斷遞增，而且是唯一的，也就是說A和B不可能有相同的提案號），這個提案號會和修改請求一同發出，任何結點在“Prepare階段”時都會拒絕其值小于當前提案號的請求。所以，結點A在向所有結點申請修改請求的時候，需要帶一個提案號，越新的提案，這個提案號就越是是最大的。

如果接收結點收到的提案號n大于其它結點發過來的提案號，這個結點會回應Yes（本結點上最新的被批準提案號），并保證不接收其它<n的提案。這樣一來，結點上在Prepare階段里總是會對最新的提案做承諾。

優化：在上述 prepare 過程中，如果任何一個結點發現存在一個更高編號的提案，則需要通知 提案人，提醒其中斷這次提案。

第二階段：Accept階段

如果提案者A收到了超過半數的結點返回的Yes，然后他就會向所有的結點發布Accept Request（同樣，需要帶上提案號n），如果沒有超過半數的話，那就返回失敗。

當結點們收到了Accept Request后，如果對于接收的結點來說，n是最大的了，那么，它就會通過request（修改這個值），如果發現自己有一個更大的提案號，那么，結點就會拒絕request（拒絕修改）。

我們可以看以，這似乎就是一個“兩段提交”的優化。其實，2PC/3PC都是分布式一致性算法的殘次版本，Google Chubby的作者Mike Burrows說過這個世界上只有一種一致性算法，那就是Paxos，其它的算法都是殘次品。

我們還可以看到：對于同一個值的在不同結點的修改提案就算是在接收方被亂序收到也是沒有問題的。

四、Raft協議(解決paxos的實現難度)

Paxos 相比 Raft 比較復雜和難以理解。角色扮演和流程比 Raft 都要啰嗦。比如 Agreement 這個流程，在 Paxos 里邊：Client 發起請求舉薦 Proposer 成為 Leader，Proposer 然后向全局 Acceptors 尋求確認，Acceptors 全部同意 Proposer 后，Proposer 的 Leader 地位得已承認，Acceptors 還得再向Learners 進行全局廣播來同步。而在 Raft 里邊，只有 Follower/Candidate/Leader 三種角色，角色本身代表狀態，角色之間進行狀態轉移是一件非常自由民主的事情。Raft雖然有角色之分但是是全民參與進行選舉的模式；但是在Paxos里邊，感覺更像議員參政模式。

三個角色

follower、candidate、leader。
最開始大家都是follower，當follower監聽不到leader，就可以自己成為candidate，發起投票

leader選舉：timeout限制

選舉的timeout

follower成為candidate的超時時間，每個follower都在150ms and 300ms之間隨機，之后看誰先timeout，誰就先成為candidate，然后它會先投自己一票，再向其他節點發起投票邀請。
如果其他節點在這輪選舉還沒有投過票，那么就給candidate投票，然后重置自己的選舉timeout。
如果得到大多數的投票就成為leader，之后定期開始向follower發送心跳。

如果兩個follower同時成為candidate的話，如果最后得到的票數相同，則等待其他follower的選擇timeout之后成為candidate，繼續開始新一輪的選舉。

log復制

leader把變動的log借助心跳同步給follower，過半回復之后才成功提交，之后再下一次心跳之后，follower也commit變動，在自己的node上生效。

分裂之后，另一個分區的follower接受不到leader的timeout，然后會有一個先timeout，成為candidate，最后成為leader。
于是兩個分區就有了兩個leader。

當客戶端有變動時，其中的leader由于無法收到過半的提交，則保持未提交狀態。有的leader的修改，可以得到過半的提交，則可以修改生效。

當分裂恢復之后，leader開始對比選舉的term，發現有更高的term存在時，他們會撤銷未提交的修改，然后以最新的為準。

五、ISR的機制(解決f容錯的2f+1成本問題)

Kafka并沒有使用Zab或Paxos協議的多數投票機制來保證主備數據的一致性，而是提出了ISR的機制（In-Sync Replicas）的機制來保證數據一致性。

ISR認為對于2f+1個副本來說，多數投票機制要求最多只能允許f個副本發生故障，如果要支持2個副本的容錯，則需要至少維持5個副本，對于消息系統的場景來說，效率太低。

ISR的運行機制如下：將所有次級副本數據分到兩個集合，其中一個被稱為ISR集合，這個集合備份數據的特點是即時和主副本數據保持一致，而另外一個集合的備份數據允許其消息隊列落后于主副本的數據。在做主備切換時，只允許從ISR集合中選擇主副本，只有ISR集合內所有備份都寫成功才能認為這次寫入操作成功。在具體實現時，kafka利用zookeeper來保持每個ISR集合的信息，當ISR集合內成員變化時，相關構件也便于通知。通過這種方式，如果設定ISR集合大小為f+1，那么可以最多允許f個副本故障，而對于多數投票機制來說，則需要2f+1個副本才能達到相同的容錯性。

參考

• 分布式系統的Raft算法

• 英文動畫演示Raft(推薦)

• paxos-by-example

• 為啥CoreOS沒用Paxos，重新搞了Raft？

總結

以上是生活随笔為你收集整理的2PC到3PC到Paxos到Raft到ISR的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。