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

09-24

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

前言

由於BASE理論需要在一致性和可用性方面做出權衡，因此湧現了很多關於一致性的演算法和協議。其中比較著名的有二階提交協議（2 Phase Commitment Protocol），三階提交協議（3 Phase Commitment Protocol）和Paxos演算法。

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

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

正文

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協議中引入解決方案。

歡迎關注技術公眾號：零壹技術棧

http://weixin.qq.com/r/VDgkPNHE1YyqrZVf921G (二維碼自動識別)

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