分散式場景之剛性事務-2PC詳解

分散式一致性

分散式場景下，多個服務同時對服務一個流程，比如電商下單場景，需要支付服務進行支付、庫存服務扣減庫存、訂單服務進行訂單生成、物流服務更新物流資訊等。如果某一個服務執行失敗，或者網路不通引起的請求丟失，那麼整個系統可能出現資料不一致的原因。

上述場景就是分散式一致性問題，追根到底，分散式一致性的根本原因在於資料的分散式操作，引起的本地事務無法保障資料的原子性引起。

分散式一致性問題的解決思路有兩種，一種是分散式事務，一種是儘量透過業務流程避免分散式事務。分散式事務是直接解決問題，而業務規避其實透過解決出問題的地方(解決提問題的人)。其實在真實業務場景中，如果業務規避不是很麻煩的前提，最優雅的解決方案就是業務規避。

事務分類

分散式事務實現方案從型別上去分剛性事務、柔型事務。剛性事務：通常無業務改造，強一致性，原生支援回滾/隔離性，低併發，適合短事務。柔性事務：有業務改造，最終一致性，實現補償介面，實現資源鎖定介面，高併發，適合長事務。

剛性事務：XA 協議（2PC、JTA、JTS）、3PC

柔型事務：TCC/FMT、Saga（狀態機模式、Aop模式）、本地事務訊息、訊息事務（半訊息）

2PC定義

2PC全稱Two-phaseCommit，中文名是二階段提交，是XA規範的實現思路，XA規範是 X/Open DTP 定義的交易中介軟體與資料庫之間的介面規範（即介面函式），交易中介軟體用它來通知資料庫事務的開始、結束以及提交、回滾等。XA 介面函式由資料庫廠商提供。

X/Open DTP是X/Open 組織（即現在的 Open Group ）1994定義的分散式事務處理模型。XA規模型包括應用程式（ AP ）、事務管理器（ TM ）、資源管理器（ RM ）、通訊資源管理器（ CRM ）四部分。一般，常見的事務管理器（ TM ）是交易中介軟體，常見的資源管理器（ RM ）是資料庫，常見的通訊資源管理器（ CRM ）是訊息中介軟體。

2PC 通常使用到XA中的三個角色TM、AP

AP：事務發起方，通常為微服務自身；定義事務邊界(事務開始、結束)，並訪問事務邊界內的資源

TM：事務協調方，事務操作總控；管理事務全域性事務，分配事務唯一標識，監控事務的執行進度，負責事務的提交、回滾、失敗恢復。

RM：本地事務資源，根據協調方命令進行操作；管理本地共享資源(既資料庫)。

2PC流程

2PC 分成2個階段，第一階段：請求階段（commit-request phase，或稱表決階段，voting phase）和第二階段：提交階段（commit phase）。

表決階段：事務協調者(TM)序列給每個參與者(RM)傳送Prepare訊息，每個參與者要麼直接返回失敗，要麼在本地SQL執行、記錄事務日誌(Undo、Redo)，但不提交，到達一種“萬事俱備，只欠東風”的狀態。

可以進一步將準備階段分為以下三個步驟：

1）TM序列向每個參與者節點詢問是否可以執行提交操作，並等待各參與者節點的響應。

2）參與者節點執行詢問的所有SQL語句，並將Undo和Redo寫入日誌。

3）各參與者節點響應TM發起的詢問。如果參與者節點的事務操作實際執行成功，則返回一個”success”訊息；如果參與者節點的事務操作實際執行失敗，則返回一個”abort”訊息。

提交階段：如果TM收到了參與者的失敗訊息或者超時，直接給每個參與者傳送回滾(Rollback)訊息；否則，傳送提交(Commit)訊息；參與者根據TM的指令執行提交或者回滾操作，釋放所有事務處理過程中使用的鎖資源。(注意:必須在最後階段釋放鎖資源)

分支一--當TM從所有參與者節點獲得的相應訊息都為”success”時：

1）TM向所有參與者節點發出”正式提交(commit)”的請求。

2）參與者節點正式完成操作，並釋放在整個事務期間內佔用的資源。

3）參與者節點向TM傳送”完成”訊息。

4）TM受到所有參與者節點反饋的”完成”訊息後，完成事務。

分支二--如果任一參與者節點在第一階段返回的響應訊息為”abort”，或者 TM在第一階段的詢問超時之前無法獲取所有參與者節點的響應訊息時：

1）TM向所有參與者節點發出”回滾操作(rollback)”的請求。

2）參與者節點利用之前寫入的Undo資訊執行回滾，並釋放在整個事務期間內佔用的資源。

3）參與者節點向TM傳送”回滾完成”訊息。

4）TM受到所有參與者節點反饋的”回滾完成”訊息後，取消事務。

不管最後結果如何，第二階段都會結束當前事務。

總結

2PC雖然將XA規範方案細化成思路，也形成了流程圖，大部情況下確實能提供原子性操作，但是仍存在一定問題，所以又出現了3PC。

領取更多免費資料及影片