一文帶你系統性讀懂分布式事務的解決方案以及分布式事務協定

緣起

筆者最近在看分布式事務的時候發現網上很多資料很零散，不夠系統，看的雲裡霧裡，比如在分布式事務中的關鍵詞

2. DTP模型
3. TCC
4. XA規範
5. 兩階段型
6. 三階段型
7. JTA
8. 基于可靠消息服務的分布式事務
9. 異步確定型
10. 補償型
11. 最大努力通知型
12. 定期校對
13. sagas事務模型

這麼多關鍵詞是什麼意思？之間又有什麼關系？？

系統性的了解分布式事務協定和解決方案

什麼是協定和解決方案

先說說什麼是協定，

協定就是約定，就是提出來這個東西應該怎麼做的約定，不是一個具體的解決方案，比如大家約定了2.5寸的硬碟的接口是怎樣的，長寬高是多少，但是具體你硬碟怎麼做是你的事，你可以用塑膠做，也可以做鐵做，也可以用木頭做。

而解決方案就是具體的做法，比如上面說的硬碟用什麼材料做，在技術中往往就是說具體的架構。

分布式事務的協定

目前比較常用的分布式事務解決方案的協定有兩種

2. 強一緻的X/Open DTP模型
3. 弱一緻的TCC

在說這兩個之前簡單提一嘴XA規範

XA 就是 X/Open DTP 定義的交易中間件與資料庫之間的接口規範（即接口函數），交易中間件用它來通知資料庫事務的開始、結束以及送出、復原等。 XA 接口函數由資料庫廠商提供。      

X/Open DTP模型

X/Open 組織（即現在的 Open Group ）定義了分布式事務處理模型。 X/Open DTP 模型（ 1994 ）包括應用程式（ AP ）、事務管理器（ TM ）、資料總管（ RM ）、通信資料總管（ CRM ）四部分。一般，常見的事務管理器（ TM ）是交易中間件，常見的資料總管（ RM ）是資料庫，常見的通信資料總管（ CRM ）是消息中間件。 通常把一個資料庫内部的事務處理，如對多個表的操作，作為本地事務看待。資料庫的事務處理對象是本地事務，而分布式事務處理的對象是全局事務。 所謂全局事務，是指分布式事務處理環境中，多個資料庫可能需要共同完成一個工作，這個工作即是一個全局事務，例如，一個事務中可能更新幾個不同的資料庫。對資料庫的操作發生在系統的各處但必須全部被送出或復原。此時一個資料庫對自己内部所做操作的送出不僅依賴本身操作是否成功，還要依賴與全局事務相關的其它資料庫的操作是否成功，如果任一資料庫的任一操作失敗，則參與此事務的所有資料庫所做的所有操作都必須復原。 一般情況下，某一資料庫無法知道其它資料庫在做什麼，是以，在一個 DTP 環境中，交易中間件是必需的，由它通知和協調相關資料庫的送出或復原。而一個資料庫隻将其自己所做的操作（可恢複）影射到全局事務中。

二階段和三階段

根據X/Open DTO模型這一思想又衍生出二階段送出和三階段送出

2PC： 二階段送出(Two-phaseCommit)是指，在計算機網絡以及資料庫領域内，為了使基于分布式系統架構下的所有節點在進行事務送出時保持一緻性而設計的一種算法(Algorithm)。通常，二階段送出也被稱為是一種協定(Protocol))。在分布式系統中，每個節點雖然可以知曉自己的操作時成功或者失敗，卻無法知道其他節點的操作的成功或失敗。當一個事務跨越多個節點時，為了保持事務的ACID特性，需要引入一個作為協調者的元件來統一掌控所有節點(稱作參與者)的操作結果并最終訓示這些節點是否要把操作結果進行真正的送出(比如将更新後的資料寫入磁盤等等)。是以，二階段送出的算法思路可以概括為：參與者将操作成敗通知協調者，再由協調者根據所有參與者的回報情報決定各參與者是否要送出操作還是中止操作。所謂的兩個階段是指：第一階段：準備階段(投票階段)和第二階段：送出階段（執行階段）。

說人話就是：你第一階段詢問你的三個朋友，我們去釣魚 大保健啊？（詢問），你三個朋友都說OK呀 沒問題啊（預送出），然後你看到大家都很贊同，你就喊大家出來大保健（送出），大家就去了。如果第一階段三個朋友任何一個回複你說他去不了或者他沒有回複你是去還是不去，那麼你就會告訴你所有的朋友，本次大保健活動取消（復原）。

這裡有個問題就是第二階段你告訴你朋友，那我們去大保健吧，結果有一個哥們因為網絡原因沒收到你的通知，他也不知道第一階段其他兩個朋友到底是去還是不去，那麼他自己就不知道去還是不去，就會一直在那等你的去還是不去的通知（堵塞），也有可能他等的時間久了他就沒去，但是其他兩個收到你消息的哥們就去了，那麼就會造成資料不一緻性問題。

3PC： 三階段送出（Three-phase commit），也叫三階段送出協定（Three-phase commit protocol），是二階段送出（2PC）的改進版本。與兩階段送出不同的是，三階段送出有兩個改動點。

2. 引入逾時機制。同時在協調者和參與者中都引入逾時機制。

3. 在第一階段和第二階段中插入一個準備階段。保證了在最後送出階段之前各參與節點的狀态是一緻的。

   也就是說，除了引入逾時機制之外，3PC把2PC的準備階段再次一分為二，這樣三階段送出就有CanCommit、PreCommit、DoCommit三個階段。

說人話就是：你第一階段詢問你的三個朋友，我們去釣魚 大保健啊？（詢問），你三個朋友都說OK呀 沒問題啊（CanCommit），第二階段，你看到大家都很贊同，你就告訴你那幾個朋友，大家都說沒問題，我們準備下就去吧（PreCommit），第三階段，你就喊大家出來大保健，大家就去了（DoCommit）。如果第一階段或者第二階段三個朋友任何一個回複你說他去不了或者他沒有回複你是去還是不去，那麼你就會告訴你所有的朋友，本次大保健活動取消（復原）。

相比較二階段送出，此處新增了一個階段就是你會告訴你的朋友，大家都覺得沒問題這個階段，這樣的話，即使出現你你告訴你朋友，那我們去大保健吧，結果有一個哥們因為網絡原因沒收到你的通知，他是知道第二階段其他兩個朋友到底是去還是不去的，那麼他自己就知道去還是不去，就不會堵塞，但依然有可能第三階段你告訴大家的是本次活動取消，但有吊毛沒收到請求，那麼他自己一個人傻乎乎的去了，其他幾個收到了的又沒去，是以還是會有資料一緻性問題。隻是相比較于二階段，三階段減少了資料一緻性問題出現的機率，因為某個吊毛雖然沒收到DoCommit的請求，但是他肯定是收到了PreCommit的請求的，那麼他就會覺得，大家都說好了去，大機率是會去的。

X/Open DTP模型的實作架構

前面說的都是理論，那麼基于這些理論，在java中又有具體的實作架構，主要有

2. JOTM（java open transaction manage）
3. Atomikos，在JavaEE平台下，WebLogic、WebShare等主流商用的應用伺服器提供了JTA的實作和支援。在Tomcat下是沒有實作的，這就需要借助第三方的架構，如：Jotm,Automikos.關于DTP的​​詳細說明和在項目中使用DTP的實戰​​。其中spring對Automikos有很好的內建（JTA）。

視訊

​​讓技術不再生澀難懂 - Spring+事務，原理就是這麼簡單（主要講解了Spring中使用Automikos來實作JTA事務）​​

2PC的實作原理

先執行預送出操作，然後執行确認送出操作，僞代碼如下。

//拿到XA資料總管
XAResource rm1 = xaConn1.getXAResource();
XAResource rm2 = xaConn2.getXAResource();

//執行預送出
int rm1p = rm1.prepare(xid1); 
int rm2p = rm1.prepare(xid2); 

//确認送出或者復原
if(rm1p == XAResource.XA_OK && rm2p == XAResource.XA_OK){
  rm1.commit(xid1, onePhace);
  rm2.commit(xid1, onePhace);
}else{
  rm1.rollback(xid1);
  rm2.rollback(xid2);
}      

TCC（柔性事務，最終一緻）

簡單來說TCC也有點像2PC。隻是TCC位于業務服務層而非資源層 TCC沒有單獨的準備(Prepare)階段,Try操作兼備資源操作與準備能力 • Try操作可以靈活選擇業務資源的鎖定粒度(以業務定粒度) TCC有較高開發成本，因為你還要開發很多補償性的接口。比如原來你隻有一個金額加的接口，你現在可能需要開發一個金額減的接口以備補償的時候使用。但現在企業最不缺的就是程式員，故大多企業使用這種方式實作。TCC 分布式事務架構 ByteTCC、Himly、TCC-transaction。簡單來說這些架構可以很友善的幫你實作TCC。比如你可以在方法上加個注解來說明方法失敗後調用此方法方法進行復原。用通俗易懂的方式講解了TCC和基于可靠消息服務的分布式事務。

TCC事務又有以下幾種實作方案

2. 最大努力通知（定期校對）（最終一緻）：如果你做過支付系統的話，就會知道我們接支付寶，微信支付的時候有個場景是需要定期去查詢 支付寶，微信主動查詢支付狀态的，這就是定期校對。
3. 基于于可靠消息服務的分布式事務（最終一緻）：大體來說就是比如訂單系統在訂單送出後需要把發貨這個消息發送給物流系統，而隻要訂單系統保證這個消息能100%發送到MQ，物流系統能100%消費掉這個消息，就能實作分布式事務的最終一緻性。與TCC類似，隻是這個更适合異步的場景。

TCC的實作架構

那麼基于上面的解決方案又有具體的實作架構

2. Himly
3. TCC-transaction

視訊

​​分布式系統開發實戰篇 - TCC分布式事務實作(主要示範了TTC事務的兩個架構Himly、TCC-transaction，以及講了一些分布式事務的基礎知識)​​