## **分布式事務解決方案** #### **一、兩階段提交（2PC）** 和上一節中提到的數據庫XA事務一樣，兩階段提交就是使用XA協議的原理，我們可以從下面這個圖的流程來很容易的看出中間的一些比如commit和abort的細節。  兩階段提交這種解決方案屬于犧牲了一部分可用性來換取的一致性。在實現方面，在 .NET 中，可以借助 TransactionScop 提供的 API 來編程實現分布式系統中的兩階段提交，比如WCF中就有實現這部分功能。不過在多服務器之間，需要依賴于DTC來完成事務一致性，Windows下微軟搞的有MSDTC服務，Linux下就比較悲劇了。 另外說一句，TransactionScop 默認不能用于異步方法之間事務一致，因為事務上下文是存儲于當前線程中的，所以如果是在異步方法，需要顯式的傳遞事務上下文。 **優點：**盡量保證了數據的強一致，適合對數據強一致要求很高的關鍵領域。（其實也不能100%保證強一致） **缺點：**實現復雜，犧牲了可用性，對性能影響較大，不適合高并發高性能場景，如果分布式系統跨接口調用，目前 .NET 界還沒有實現方案。 #### **二、補償事務（TCC）** TCC 其實就是采用的補償機制，其核心思想是：針對每個操作，都要注冊一個與其對應的確認和補償（撤銷）操作。它分為三個階段： * Try 階段主要是對業務系統做檢測及資源預留 * Confirm 階段主要是對業務系統做確認提交，Try階段執行成功并開始執行 Confirm階段時，默認 Confirm階段是不會出錯的。即：只要Try成功，Confirm一定成功。 * Cancel 階段主要是在業務執行錯誤，需要回滾的狀態下執行的業務取消，預留資源釋放。 舉個例子，假入 Bob 要向 Smith 轉賬，思路大概是： 我們有一個本地方法，里面依次調用 1、首先在 Try 階段，要先調用遠程接口把 Smith 和 Bob 的錢給凍結起來。 2、在 Confirm 階段，執行遠程調用的轉賬的操作，轉賬成功進行解凍。 3、如果第2步執行成功，那么轉賬成功，如果第二步執行失敗，則調用遠程凍結接口對應的解凍方法 (Cancel)。 **優點：**跟2PC比起來，實現以及流程相對簡單了一些，但數據的一致性比2PC也要差一些 **缺點：**缺點還是比較明顯的，在2,3步中都有可能失敗。TCC屬于應用層的一種補償方式，所以需要程序員在實現的時候多寫很多補償的代碼，在一些場景中，一些業務流程可能用TCC不太好定義及處理。 #### **三、本地消息表（異步確保）** 本地消息表這種實現方式應該是業界使用最多的，其核心思想是將分布式事務拆分成本地事務進行處理，這種思路是來源于ebay。我們可以從下面的流程圖中看出其中的一些細節：  基本思路就是： 消息生產方，需要額外建一個消息表，并記錄消息發送狀態。消息表和業務數據要在一個事務里提交，也就是說他們要在一個數據庫里面。然后消息會經過MQ發送到消息的消費方。如果消息發送失敗，會進行重試發送。 消息消費方，需要處理這個消息，并完成自己的業務邏輯。此時如果本地事務處理成功，表明已經處理成功了，如果處理失敗，那么就會重試執行。如果是業務上面的失敗，可以給生產方發送一個業務補償消息，通知生產方進行回滾等操作。 生產方和消費方定時掃描本地消息表，把還沒處理完成的消息或者失敗的消息再發送一遍。如果有靠譜的自動對賬補賬邏輯，這種方案還是非常實用的。 這種方案遵循BASE理論，采用的是最終一致性，筆者認為是這幾種方案里面比較適合實際業務場景的，即不會出現像2PC那樣復雜的實現(當調用鏈很長的時候，2PC的可用性是非常低的)，也不會像TCC那樣可能出現確認或者回滾不了的情況。 **優點：**一種非常經典的實現，避免了分布式事務，實現了最終一致性。在 .NET中 有現成的解決方案。 **缺點：**消息表會耦合到業務系統中，如果沒有封裝好的解決方案，會有很多雜活需要處理。 #### **四、MQ 事務消息** 有一些第三方的MQ是支持事務消息的，比如RocketMQ，他們支持事務消息的方式也是類似于采用的二階段提交，但是市面上一些主流的MQ都是不支持事務消息的，比如 RabbitMQ 和 Kafka 都不支持。 以阿里的 RocketMQ 中間件為例，其思路大致為： 第一階段Prepared消息，會拿到消息的地址。 第二階段執行本地事務，第三階段通過第一階段拿到的地址去訪問消息，并修改狀態。 也就是說在業務方法內要想消息隊列提交兩次請求，一次發送消息和一次確認消息。如果確認消息發送失敗了RocketMQ會定期掃描消息集群中的事務消息，這時候發現了Prepared消息，它會向消息發送者確認，所以生產方需要實現一個check接口，RocketMQ會根據發送端設置的策略來決定是回滾還是繼續發送確認消息。這樣就保證了消息發送與本地事務同時成功或同時失敗。  遺憾的是，RocketMQ并沒有 .NET 客戶端。有關 RocketMQ的更多消息，大家可以查看[這篇博客](http://www.jianshu.com/p/453c6e7ff81c) **優點：**實現了最終一致性，不需要依賴本地數據庫事務。 **缺點：**實現難度大，主流MQ不支持，沒有.NET客戶端，RocketMQ事務消息部分代碼也未開源。 #### **五、Sagas 事務模型** Saga事務模型又叫做長時間運行的事務（Long-running-transaction）, 它是由普林斯頓大學的H.Garcia-Molina等人提出，它描述的是另外一種在沒有兩階段提交的的情況下解決分布式系統中復雜的業務事務問題。你可以在[這里](https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf)看到 Sagas 相關論文。 我們這里說的是一種基于 Sagas 機制的工作流事務模型，這個模型的相關理論目前來說還是比較新的，以至于百度上幾乎沒有什么相關資料。 該模型其核心思想就是拆分分布式系統中的長事務為多個短事務，或者叫多個本地事務，然后由 Sagas 工作流引擎負責協調，如果整個流程正常結束，那么就算是業務成功完成，如果在這過程中實現失敗，那么Sagas工作流引擎就會以相反的順序調用補償操作，重新進行業務回滾。 比如我們一次關于購買旅游套餐業務操作涉及到三個操作，他們分別是預定車輛，預定賓館，預定機票，他們分別屬于三個不同的遠程接口。可能從我們程序的角度來說他們不屬于一個事務，但是從業務角度來說是屬于同一個事務的。  他們的執行順序如上圖所示，所以當發生失敗時，會依次進行取消的補償操作。