前言
由於BASE理論需要在一致性和可用性方面做出權衡，因此湧現了很多關於一致性的演算法和協議。其中比較著名的有二階提交協議（2 Phase Commitment Protocol），三階提交協議（3 Phase Commitment Protocol）和Paxos演算法。
本文要介紹的2PC協議，分為兩個階段提交一個事務。並通過協調者和各個參與者的配合，實現分散式一致性。
兩個階段事務提交協議，由協調者和參與者共同完成。
| 角色 | XA概念 | 作用 |
|---|---|---|
| 協調者 | 事務管理器 | 協調各個參與者，對分散式事務進行提交或回滾 |
| 參與者 | 資源管理器 | 分散式叢集中的節點 |
正文
1. 分散式事務
分散式事務是指會涉及到操作多個資料庫的事務，其實就是將對同一庫事務的概念擴大到了對多個庫的事務。目的是為了保證分散式系統中的資料一致性。
分散式事務處理的關鍵是：
- 需要記錄事務在任何節點所做的所有動作；
- 事務進行的所有操作要麼全部提交，要麼全部回滾。
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規範程式設計規範
-
配置TM，給TM註冊RM作為資料來源。其中，一個TM可以註冊多個RM。
-
AP向TM發起一個全域性事務。這時，TM會傳送一個XID（全域性事務ID）通知各個RM。
-
AP從TM獲取資源管理器的代理（例如：使用JTA介面，從TM管理的上下文中，獲取出這個TM所管理的RM的JDBC連線或JMS連線）。
-
AP通過從TM中獲取的連線，間接操作RM進行業務操作。TM在每次AP操作時把XID傳遞給RM，RM正是通過這個XID關聯來操作和事務的關係的。
-
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協議中引入解決方案。
相關連結
- 分散式理論(一) - CAP定理
- 分散式理論(二) - BASE理論
- 分散式理論(三) - 2PC協議
- 分散式理論(四) - 3PC協議
- 分散式理論(五) - 一致性演算法Paxos
- 分散式理論(六) - 一致性協議Raft
歡迎掃碼關注公眾號：零壹技術棧
本帳號將持續分享後端技術乾貨，包括虛擬機器基礎，多執行緒程式設計，高效能框架，非同步、快取和訊息中介軟體，分散式和微服務，架構學習和進階等學習資料和文章。