一致性協議-2PC，3PC，Paxos

一致性協議

2PC

2PC即二階段提交，是計算機網絡尤爲是在數據庫領域內，爲了使基於分佈式系統架構下的全部節點在進行事務處理過程當中可以保持原子性和一致性而設計的一種算法。
協議說明：二階段提交協議是將事務的提交過程分紅兩個階段來進行處理。
階段一：提交事務請求
投票階段
階段二：執行事務提交

執行階段

優缺點

優勢：原理簡單，實現方便
缺點：同步阻塞、單點問題、腦裂、太過保守

同步阻塞

在二階段提交的執行過程當中，全部參與該事務操做的邏輯都處於阻塞狀態

單點問題

協調者的角色在整個二階段提交協議中起到了很是重要的做用，是單點的。

數據不一致

在二階段提交協議的階段二，即執行事務提交的時候，commit請求並未發送到全部的參與者。

太過保守

若是在協調者指示參與者進行事務提交詢問的過程當中，參與者出現故障而致使協調者始終沒法獲取到全部參與者的響應信息的換，這時協調者只能依靠自身的超時機制來判斷是否須要中斷事務，這樣的策略顯得比較保守。換句話說，二階段提交協議沒有涉及較爲完善的容錯機制，任意一個節點的失敗都會致使整個事務的失敗。

3PC

三階段提交是2PC的改進版，將二階段提交協議的「提交事務請求」過程一分爲二，造成了由CanCommit,PreCommit和doCommit三個階段組成的事務處理協議。

階段一：CanCommit

1. 事務詢問
2. 各參與者向協調者反饋事務詢問的響應

階段二：PreCommit，兩種狀況
執行事務預提交：協調者從全部的參與者得到的反饋都是yes響應，那麼就會執行事務預提交。

1. 發送預提交請求
2. 事務預提交
3. 各參與者向協調者反饋事務執行的響應

中斷事務：假如任何一個參與者向協調者反饋了No響應，或者在等待超時以後，協調者尚沒法接收到全部參與者的反饋響應，那麼就會中斷事務

1. 發送中斷請求
2. 中斷事務

階段三：doCommit，兩種狀況

執行提交：

1. 發送提交請求
2. 事務提交
3. 反饋事務提交結果
4. 完成事務

中斷事務

1. 發送中斷請求
2. 事務回滾
3. 反饋事務回滾結果
4. 中斷事務

須要注意，一旦進入階段三，可能會存在如下兩種故障。

• 協調者出現問題
• 協調者和參與者之間的網絡出現故障

不管出現那種狀況，最終都會致使參與者沒法及時接受到來自協調者的doCommit或者abort請求，針對這樣的異常狀況，參與者都會在等待超時以後，繼續進行事務提交。

優缺點

優勢：相較於2PC，3PC最大的有點就是下降了參與者的阻塞範圍，而且可以在單點故障後繼續達成一致。
缺點：容易出現數據不一致性

Paxos

分佈式一致性協議是一種基於消息傳遞且具備高度容錯特性的一致性算法，是目前公認的解決分佈式一致性問題最有效的算法之一。
Paxos算法須要解決的問題就是如何在一個可能發生上述異常的分佈式系統中，快速且正確地在集羣內部對某個數據的值達成一致性，而且保證不論發生以上任何異常，都不會破壞整個系統的一致性。

問題描述

假設有一組能夠提出提案的進程集合，那麼對於一個一致性算法來講須要保證如下幾點：

• 在這些被提出的提案中，只有一個會被選定
• 若是沒有填被提出，那麼就不會有被選定的提案
• 當一個提案被選定後，進程應該能夠獲取被選定的提案信息

對於一致性來講，安全性需求以下：

• 只有被提出的提案才能被選定
• 只能有一個值被選定
• 若是某個進程認爲某個提案被選定了，那麼這個提案必須是真的被選定的那個

從總體來講，Paxos算法的目標就是要保證最終有一個提案會被選定，當提案被選定後，進程最終也能獲取到被選定的提案。

有三種參與角色，咱們用Proposer，Acceptor和Learner來表示

假設不一樣參與者之間能夠經過收發消息來進行通訊，那麼：

• 每一個參與者以任意的速度執行，可能會由於出錯而中止，也可能會重啓。同時，即便一個提案被選定後，全部的參與者也都有可能失敗或重啓，所以除非那些失敗或重啓的參與者能夠記錄某些信息，不然將沒法肯定最終的值。
• 消息在傳輸過程當中可能會出現不可預知的延遲，也可能會重複或丟失，可是消息不會損壞，即消息內容不會被篡改

推到過程

P1：一個Acceptor必須批准它收到的第一個提案。


由於以上兩種狀況，在P1的基礎上，再加上一個提案
被選定須要由半數以上的Acceptor批准的需求暗示着一個Acceptor必須可以批准不止一個提案。

咱們使用一個全局的編號來惟一標識每個被Acceptor批准的提案，當一個具備某Value值的提案被半數以上的Acceptor批准後，咱們就認爲該Value被選定了，此時咱們也認爲該提案被選定了。

P2：若是編號爲M0、Value值爲V0的提案被選定了，那麼全部比編號M0更高的，且被選定的提案，其Value值必須也是V0.
一個提案要被選定，其首先必須被至少一個Acceptor批准，所以咱們能夠經過知足以下條件來知足P2。
P2a：若是編號爲M0、Value值爲V0的提案被選定了，那麼全部比編號M0更高的，且被Acceptor批准的提案，其Value值必須也是V0。

P2b：若是一個提案【M0,V0】被選定後，那麼以後任何Proposer產生的編號更高的提案，其Value值都爲V0。
由於一個提案必須在被Proposer提出後才能被Acceptor批准，所以P2b包含了P2a，進而包含了P2。
論證P2b成立。

P2c：對於任意的Mn和Vn，若是提案【Mn，Vn】被提出，那麼確定存在一個由半數以上的Acceptor組成的集合S，知足一下兩個條件中的任意一個。

• S中不存在任何批准過編號小於Mn的提案，其中編號最大的那個提案其Value值是Vn。

Proposer生整天
Proposer選擇一個新的提案編號Mn，而後向某個Acceptor集合的成員發送請求，要求該集合中的Acceptor作出以下回應。

• 向Proposer承諾，保證再也不批准任何編號小於Mn的提案
• 若是Acceptor已經批准過任何提案，那麼其就向Proposer反饋當前該Acceptor已經批准的編號小於Mn但爲最大編號的哪一個提案的值。

Acceptor批准提案

• Prepare請求：Acceptor能夠在任什麼時候候響應一個Prepare請求
• Accept請求：在不違背Accept現有承諾的前提下，能夠任意響應Accept請求。

算法優化

儘量地武略Prepare請求

算法陳述

階段一

1. Proposer選擇一個提案編號Mn，而後向Acceptor的某個超過半數的子集成員發送編號爲Mn的Prepare請求。
2. 若是一個Acceptor收到一個編號爲Mn的Prepare請求，且編號Mn大於該Acceptor已經響應的全部Prepare請求的編號，那麼它就會將它已經批准過的最大編號的提案做爲響應反饋給Propser，同時該Acceptor會承諾不會在批准任何編號小於Mn的提案。

階段二

1. 若是Proposer收到來自半數以上的Acceptor對於其發出的編號Mn的Prepare請求的響應，那麼它就會發送一個針對[Mn，Vn]提案的Accept請求給Acceptor。
2. 若是Acceptor收到這個針對[Mn，Vn]提案的Accept請求，只要該Acceptor還沒有對編號大於Mn的Prepare請求作出響應，它就能夠經過這個提案。