2PC與 3PC

在分散式系統中,每個節點都明確知道自己事務操作的成功或失敗,但無法獲取其他分散式節點的操作結果。因此當一個事務需要跨節點進行事務操作時,需要引入協調者(Coordinator)元件來統一排程所有分散式節點的執行邏輯,這些被排程的節點稱為參與者(Participant)。
協調者負責排程參與者的行為,最終決定這些參與者是否提交事務。基於這個思想衍生出二階段提交和三階段提交兩種協議。

2PC

2PC, Two-Phase Commit 的縮寫,即二階段提交。

協議說明

二階段提交協議是將事務提交過程分成了兩個階段來進行處理,執行流程如下:
階段一:提交事務請求
1.事務詢問。協調者向所有的參與者傳送事務內容,詢問是否可以執行事務提交操作,並開始等待各參與者的相應。
2. 執行事務 。各參與節點執行事務操作,並將Undo和Redo資訊記入事務日誌中。
3. 各參與者向協調者反饋事務詢問的相應。 如果參與者執行了事務操作,則反饋給協調者yes相應,表示事務可以執行。如果沒有成功執行,則犯規給No。

由於上面的內容相當於協調者組織參與者的投票,所以二階段提交協議的第一階段也被稱為投票階段。
階段二:執行事務提交
在階段二中,協調者根據參與者反饋情況來決定最終是否可以進行事務提交操作。包含兩種情況:
1.執行事務提交。 如果所有的參與者都反饋YES,則執行事務提交。 協調者向所有參與者傳送事務提交》參與者提交事務》參與者反饋事務提交結果》協調者收到所有參與者的反饋訊息,完成事務提交。
2. 中斷事務。 加入存在參與者相應為NO或者超時,那麼需要中斷事務。 傳送回滾請求》事務回滾》反饋事務回滾結果》中斷事務。

優缺點

優點:原理簡單,實現方便
缺點:同步阻塞,單點問題

3PC

3PC,Three-Phase Commit,三階段提交協議,由CanCommit、PreCommit、Do Commit三階段組成。

階段一:Can Commit

  1. 事務詢問。協調者向參與者傳送一個包含事務內容的canCommit請求,詢問是否可以執行事務提交操作,並開始等待參與者相應。
  2. 個參與者向協調者反饋事務詢問的相應。

階段二:PreCommit

執行事務PreCommit

假如協調者獲取的所有相應都是YES則執行事務預提交。
1.傳送預提交請求。
2.事務預提交
3.各參與中向協調者反饋事務執行結果的相應。

中斷事務

假如協調者獲取的相應存在NO,或者等待超時,則中斷事務。
1. 傳送中斷請求
2. 中斷事務

階段三:DOCommit

真正的事務提交,存在兩種結果:

執行提交

1.傳送提交請求 協調者由預提交轉換到提交狀態,向所有參與者傳送doCommit請求
2.事務提交 參與者收到doCommit請求後,執行事務提交
3. 反饋事務提交結果 參與者完成事務提交後,向協調者傳送ACK訊息
4. 完成事務 協調者接收到所有參與者反饋的ACK訊息後,完成事務

中斷事務

1,傳送中斷請求
2,事務回滾
3,反饋事務回滾結果
4,中斷事務
進入階段三也存在兩種故障:
1,協調者出現問題
2,協調者和參與者網路出現問題。

Paxos演算法

Paxos演算法詳解

Paxos演算法的核心一致性演算法即 synod演算法。

問題描述

假設一組可以提出提案的程序集合,那麼對於一個一致性演算法來說需要保證以下幾點:
* 在這些被提出的提案中,只有一個會被選定
* 如果沒有提案被提出,那麼就不會有被選定的提案
* 當一個提案被選定後,程序可以獲取被選定的提案資訊

對於一致性來說,安選型需求如下:
* 只有被提出的提案才能被選定
* 只能有一個值被選定
* 如果某個程序認為某個提案被選定了,那麼這個提案必須是真的被選定的那個

在Paxos演算法中,有三個參與角色,Proposer、Acceptor、Learner。在具體的實現中,一個程序不止一種角色。假設不同參與者之間可以通過手法訊息來進行通訊,那麼:
* 每個參與者以任意的速度進行,可能會因為出錯而停止,也可能重啟。同時,及時一個提案被選定後,也可能所有的參與者都會失敗或重啟,因此除非那些失敗或者重啟的參與者都可以記錄某些資訊,否則無法確定最終的值。
* 訊息在傳輸過程中可能會出現不可預知的延遲,也可能重複或丟失,但是訊息不會被損壞,即訊息不會被篡改。

提案的選定

要選定一個唯一提案的最簡單方式就是隻有一個Accpetor存在,Proposer傳送提案給Accpetor, Accpetor選擇第一個提案。但是一旦唯一的Acceptor故障,整體系統會故障。
最好的方案,是適應多個Acceptor避免Acceptor的單點問題。多個Acceptor的選取:Proposer向一個Acceptor集合傳送提案,同樣集合中的每個Acceptor都可能會批准該提案,當有足夠多的Acceptor批准這個提案的時候,我們就認為該提案被選定了。我們假設足夠多的Acceptor是整個Acceptor集合的一個子集,並且讓這個集合大得可以包含Acceptor集合中的大多數成員,因為任意兩個包含大多數Acceptor的子集都至少有一個公共成員。我們再規定,每一個Acceptor最多隻能批准一個天,那麼就能保證只有一個提案被選定了。

推導過程

在沒有訊息丟失和失敗的情況下,我們希望即使在只有一個提案被提出的情況下,仍然可以選出一個天,就暗示如下:
P1:一個Acceptor必須批准它收到的第一個提案。
上面的問題引出一個問題:當多個提案被不同的Proposer同時提出,這可能導致雖然每個Acceptor都批准它收到的第一個提案,但是美譽一個提案是由多數人都批准的。
在P1的基礎上,再加上一個天被選定需要由半數以上的Acceptor批准的需求,按時一個Acceptor必須能夠批准不止一個提案。在這裡我們使用一個全域性編號來唯一標識每一個被Acceptor批准的提案,當一個提案被半數以上的Acceptor批准後,我們就認為該提案被選定。
P2:如果編號為M1、Value為V1的提案被選定了,那麼所有比編號M1更高的,且被選定的提案,其Value值必須是V1。
因為提案的編號是唯一的,條件2保證了只有一個Value(提案具體的內容)被選定這一關鍵屬性。同事一個提案要被選定,首先必須只有一個Acceptor批准,由此我們通過滿足如下條件來滿足P2:
*P2a:如果編號為M0、Value為V0的提案被選定了,那麼所有比編號M0更高,且被批准的提案,其Value必須為V0.
如上,可能存在問題,某個Acceptor未收到任何訊息,提案已經被選定了。需要對P2a進行強化:
* P2b:如果一個提案 M0 V0 被選定後,那麼任何Proposer產生的編號更高的提案,其Value都為V0。

因為一個提案必須被Proposer提出後才能被Acceptor批准,因此P2b包含了P2a,進而包含了P2,所以,P2b成立即可:
假設某個提案M0 V0已經被選定了,證明任何編號Mn > M0的天,其value值都為V0。

數學歸納法證明

我們可以通過對Mn進行第二數學歸納法來進行證明,也就是說需要證明一下結論:
假設編號M0到Mn-1之間的提案,其Value值都是V0,證明編號為Mn的提案的Value值也為V0。
因為編號M0的提案已經被選定了,這就意味肯定存在一個由半數以上的Acceptor組成的集合C,C中的每個Acceptor都批准了改提案。再假設,M0的提案也被選定意味著:
C中的每個Acceptor都批准了一個編號在M0到Mn-1範圍內的提案,並且每個編號在m0到Mn-1範圍內的被Acceptor批准的提案,其Value都為V0。
因為任何包含半數以上的Acceptor的集合S都至少包含C中的一個成員,因此我們可以認為如果保持了下面的P2c的不變形,那麼編號為Mn的天的Value也是V0。
P2c:對於任意的Mn和Vn,如果Mn Vn被提出,那麼肯定存在一個由半數以上的Acceptor組成的集合S,滿足一下兩個條件中的任意一個。
* S中不存在任何批准過編號下小於Mn的提案的Acceptor.
* 選取S中所有的Acceptor批准的編號小於Mn的提案,其中編號最大的那個提案的Value是Vn

Acceptor批准提案

一個Acceptor可能會收到Proposer的兩種請求,分別是Prepare和Accept請求,對這兩個請求做出的相應的條件分別如下:
* Prepare請求:Acceptor可以在任何時候相應一個Prepare請求
* Accept請求:在不違背Accept現有承諾的前提下,可以任意相應Accept請求

因此,對Acceptor邏輯處理的約束條件定義如下;
* P1a:一個Acceptor只要尚未相應任何編號大於Mn的Prepare請求,那麼它就可以接受這個編號為Mn的提案

演算法陳述

綜合之前的內容,結合Proposer和Acceptor對提案的處理,得到如下類似兩階段提交的演算法執行過程:

階段一

  1. Proposer選擇一個提案編號Mn,然後向Acceptor的某個超過半數的子整合員傳送編號為Mn的Prepare請求。
  2. 如果一個Acceptor接收到一個編號為Mn的Prepare請求,且編號Mn大於該Acceptor已經相應的所有Prepare請求的編號,那麼它就會對它已經批准的過的最大編號的提案最為響應反饋給Proposer,同時該Acceptor承諾不會再批准編號小於Mn的提案。

階段二

1,如果Proposer收到來自半數以上的Acceptor對於其發出的編號為Mn的Prepare請求的相應,那麼它就會發出一個針對Mn Vn的提案給Acceptor。
2,如果Acceptor收到這個針對Mn Vn的提案的Acceptor請求,只要該Acceptor尚未對編號大於Mn的Prepare請求做出相應,它就通過這個提案。

提案的獲取

Learner獲取提案分為以下幾個方案:
* Learner獲取一個已經被選定的提案的前提是,該提案已經被半數以上的Acceptor批准,因此,最簡單的做法就是一旦Acceptor批准了一個提案,就將該提案發送給所有的Learner。 優點:快速選定提案 缺點:內個Acceptor與所有的Learner逐個通訊,通訊次數過多。
* 所有的Acceptor將他們對提案的批准都統一發給特定的主Learner,不考慮拜占庭將軍問題前提下,當一個議案被選中後,主Learner負責通知其他Learner。優點:通訊次數較少。缺點:主Learner可能會故障。
* 結合方案二,我們將主Learner作為一個集合來處理,則解決上述兩個問題。

通過選取主Proposer保證演算法的活性

Proposer P1提出了M1提案,完成了階段一,P2同時提出M2提案完成階段一,於是Acceptor不再批准M2的提案。當P1進入第二階段時,會被忽略,於是p1再次進入第一階段,獲取M3 , M3大於M2,由導致P2在第二階段忽略,由此進入死迴圈。
為了解決以上問題,選取一個主Proposer,並規定,只有主Proposer才能提出議案。這樣子,只要主Proposer和過半的Acceptor正常通訊,凡是主Proposer提出一個編號更改的提案,該提案會被批准,當發現有更大的提案時,則丟棄當前的較小提案。