分佈式理論(三) - 2PC協議

前言

因爲BASE理論須要在一致性和可用性方面作出權衡，所以涌現了不少關於一致性的算法和協議。其中比較著名的有二階提交協議（2 Phase Commitment Protocol），三階提交協議（3 Phase Commitment Protocol）和Paxos算法。

本文要介紹的2PC協議，分爲兩個階段提交一個事務。並經過協調者和各個參與者的配合，實現分佈式一致性。

兩個階段事務提交協議，由協調者和參與者共同完成。

角色	XA概念	做用
協調者	事務管理器	協調各個參與者，對分佈式事務進行提交或回滾
參與者	資源管理器	分佈式集羣中的節點

正文

1. 分佈式事務

分佈式事務是指會涉及到操做多個數據庫的事務，其實就是將對同一庫事務的概念擴大到了對多個庫的事務。目的是爲了保證分佈式系統中的數據一致性。

分佈式事務處理的關鍵是：

1. 須要記錄事務在任何節點所作的全部動做；
2. 事務進行的全部操做要麼所有提交，要麼所有回滾。

2. XA規範

2.1. XA規範的組成

XA規範是由 X/Open組織（即如今的 Open Group ）定義的分佈式事務處理模型。 X/Open DTP 模型（ 1994 ）包括：

• 應用程序（ AP ）
• 事務管理器（ TM ）：交易中間件等
• 資源管理器（ RM ）：關係型數據庫等
• 通訊資源管理器（ CRM ）：消息中間件等

2.2. XA規範的定義

XA規範定義了交易中間件與數據庫之間的接口規範（即接口函數），交易中間件用它來通知數據庫事務的開始、結束以及提交、回滾等。而XA接口函數由數據庫廠商提供。

二階提交協議和三階提交協議就是基於XA規範提出的其中，二階段提交就是實現XA分佈式事務的關鍵。

2.3. XA規範編程規範

1. 配置TM，給TM註冊RM做爲數據源。其中，一個TM能夠註冊多個RM。

2. AP向TM發起一個全局事務。這時，TM會發送一個XID（全局事務ID）通知各個RM。

3. AP從TM獲取資源管理器的代理（例如：使用JTA接口，從TM管理的上下文中，獲取出這個TM所管理的RM的JDBC鏈接或JMS鏈接）。

4. AP經過從TM中獲取的鏈接，間接操做RM進行業務操做。TM在每次AP操做時把XID傳遞給RM，RM正是經過這個XID關聯來操做和事務的關係的。

5. AP結束全局事務時，TM會通知RM全局事務結束。開始二段提交，也就是prepare - commit的過程。

XA規範的流程，大體如圖所示：

3. 二階段提交（2PC）

3.1. 二階段提交的定義

二階段提交的算法思路能夠歸納爲：每一個參與者將操做成敗通知協調者，再由協調者根據全部參與者的反饋情報，決定各參與者是否要提交操做仍是停止操做。

所謂的兩個階段分別是：

• 第一階段：準備階段（投票階段）
• 第二階段：提交階段（執行階段）

3.1.1. 準備階段

準備階段分爲三個步驟：

a. 事務詢問

協調者向全部的參與者詢問，是否準備好了執行事務，並開始等待各參與者的響應。

b. 執行事務

各參與者節點執行事務操做。若是本地事務成功，將Undo和Redo信息記入事務日誌中，但不提交；不然，直接返回失敗，退出執行。

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

若是參與者成功執行了事務操做，那麼就反饋給協調者 Yes響應，表示事務能夠執行提交；若是參與者沒有成功執行事務，就返回No給協調者，表示事務不能夠執行提交。

3.1.2. 提交階段

在提交階段中，會根據準備階段的投票結果執行2種操做：執行事務提交，中斷事務。

提交事務過程以下：

a. 發送提交請求

協調者向全部參與者發出commit請求。

b. 事務提交

參與者收到commit請求後，會正式執行事務提交操做，並在完成提交以後，釋放整個事務執行期間佔用的事務資源。

c. 反饋事務提交結果

參與者在完成事務提交以後，向協調者發送Ack信息。

d. 事務提交確認

協調者接收到全部參與者反饋的Ack信息後，完成事務。

中斷事務過程以下：

a. 發送回滾請求

協調者向全部參與者發出Rollback請求。

b. 事務回滾

參與者接收到Rollback請求後，會利用其在提交階段種記錄的Undo信息，來執行事務回滾操做。在完成回滾以後，釋放在整個事務執行期間佔用的資源。

c. 反饋事務回滾結果

參與者在完成事務回滾以後，想協調者發送Ack信息。

d. 事務中斷確認

協調者接收到全部參與者反饋的Ack信息後，完成事務中斷。

3.1. 二階段提交的優缺點

• 優勢：原理簡單，實現方便。
• 缺點：同步阻塞，單點問題，數據不一致，容錯性很差。

同步阻塞

在二階段提交的過程當中，全部的節點都在等待其餘節點的響應，沒法進行其餘操做。這種同步阻塞極大的限制了分佈式系統的性能。

單點問題

協調者在整個二階段提交過程當中很重要，若是協調者在提交階段出現問題，那麼整個流程將沒法運轉。更重要的是，其餘參與者將會處於一直鎖定事務資源的狀態中，而沒法繼續完成事務操做。

數據不一致

假設當協調者向全部的參與者發送commit請求以後，發生了局部網絡異常，或者是協調者在還沒有發送完全部 commit請求以前自身發生了崩潰，致使最終只有部分參與者收到了commit請求。這將致使嚴重的數據不一致問題。

容錯性很差

若是在二階段提交的提交詢問階段中，參與者出現故障，致使協調者始終沒法獲取到全部參與者的確認信息，這時協調者只能依靠其自身的超時機制，判斷是否須要中斷事務。顯然，這種策略過於保守。換句話說，二階段提交協議沒有設計較爲完善的容錯機制，任意一個節點是失敗都會致使整個事務的失敗。

小結

對於2PC協議存在的同步阻塞、單點問題，將在下一篇文章的3PC協議中引入解決方案。

相關連接

1. 分佈式理論(一) - CAP定理
2. 分佈式理論(二) - BASE理論
3. 分佈式理論(三) - 2PC協議
4. 分佈式理論(四) - 3PC協議
5. 分佈式理論(五) - 一致性算法Paxos
6. 分佈式理論(六) - 一致性協議Raft

---

歡迎掃碼關注公衆號：零壹技術棧

本賬號將持續分享後端技術乾貨，包括虛擬機基礎，多線程編程，高性能框架，異步、緩存和消息中間件，分佈式和微服務，架構學習和進階等學習資料和文章。