聊聊分佈式事務，再說說解決方案

時間 2020-05-09

原文原文鏈接

前言

最近好久沒有寫博客了，一方面是由於公司事情最近比較忙，另一方面是由於在進行 CAP 的下一階段的開發工做，不過目前已經告一段落了。html

接下來仍是開始咱們今天的話題，說說分佈式事務，或者說是我眼中的分佈式事務，由於每一個人可能對其的理解都不同。java

分佈式事務是企業集成中的一個技術難點，也是每個分佈式系統架構中都會涉及到的一個東西，特別是在微服務架構中，幾乎能夠說是沒法避免，本文就分佈式事務來簡單聊一下。git

數據庫事務

在說分佈式事務以前，咱們先從數據庫事務提及。數據庫事務可能你們都很熟悉，在開發過程當中也會常用到。可是即便如此，可能對於一些細節問題，不少人仍然不清楚。好比不少人都知道數據庫事務的幾個特性：原子性(Atomicity )、一致性( Consistency )、隔離性或獨立性( Isolation)和持久性(Durabilily)，簡稱就是ACID。可是再往下好比問到隔離性指的是什麼的時候可能就不知道了，或者是知道隔離性是什麼可是再問到數據庫實現隔離的都有哪些級別，或者是每一個級別他們有什麼區別的時候可能就不知道了。程序員

本文並不打算介紹這些數據庫事務的這些東西，有興趣能夠搜索一下相關資料。不過有一個知識點咱們須要瞭解，就是假如數據庫在提交事務的時候忽然斷電，那麼它是怎麼樣恢復的呢？爲何要提到這個知識點呢？由於分佈式系統的核心就是處理各類異常狀況，這也是分佈式系統複雜的地方，由於分佈式的網絡環境很複雜，這種「斷電」故障要比單機多不少，因此咱們在作分佈式系統的時候，最早考慮的就是這種狀況。這些異常可能有機器宕機、網絡異常、消息丟失、消息亂序、數據錯誤、不可靠的TCP、存儲數據丟失、其餘異常等等...github

咱們接着說本地事務數據庫斷電的這種狀況，它是怎麼保證數據一致性的呢？咱們使用SQL Server來舉例，咱們知道咱們在使用 SQL Server 數據庫是由兩個文件組成的，一個數據庫文件和一個日誌文件，一般狀況下，日誌文件都要比數據庫文件大不少。數據庫進行任何寫入操做的時候都是要先寫日誌的，一樣的道理，咱們在執行事務的時候數據庫首先會記錄下這個事務的redo操做日誌，而後纔開始真正操做數據庫，在操做以前首先會把日誌文件寫入磁盤，那麼當忽然斷電的時候，即便操做沒有完成，在從新啓動數據庫時候，數據庫會根據當前數據的狀況進行undo回滾或者是redo前滾，這樣就保證了數據的強一致性。數據庫

接着，咱們就說一下分佈式事務。編程

分佈式理論

當咱們的單個數據庫的性能產生瓶頸的時候，咱們可能會對數據庫進行分區，這裏所說的分區指的是物理分區，分區以後可能不一樣的庫就處於不一樣的服務器上了，這個時候單個數據庫的ACID已經不能適應這種狀況了，而在這種ACID的集羣環境下，再想保證集羣的ACID幾乎是很難達到，或者即便能達到那麼效率和性能會大幅降低，最爲關鍵的是再很難擴展新的分區了，這個時候若是再追求集羣的ACID會致使咱們的系統變得不好，這時咱們就須要引入一個新的理論原則來適應這種集羣的狀況，就是 CAP 原則或者叫CAP定理，那麼CAP定理指的是什麼呢？服務器

CAP定理

CAP定理是由加州大學伯克利分校Eric Brewer教授提出來的，他指出WEB服務沒法同時知足一下3個屬性：網絡

一致性(Consistency) ：客戶端知道一系列的操做都會同時發生(生效)
可用性(Availability) ：每一個操做都必須以可預期的響應結束
分區容錯性(Partition tolerance) ：即便出現單個組件沒法可用,操做依然能夠完成

具體地講在分佈式系統中，在任何數據庫設計中，一個Web應用至多隻能同時支持上面的兩個屬性。顯然，任何橫向擴展策略都要依賴於數據分區。所以，設計人員必須在一致性與可用性之間作出選擇。架構

這個定理在迄今爲止的分佈式系統中都是適用的！ 爲何這麼說呢？

這個時候有同窗可能會把數據庫的2PC（兩階段提交）搬出來講話了。OK，咱們就來看一下數據庫的兩階段提交。

對數據庫分佈式事務有了解的同窗必定知道數據庫支持的2PC，又叫作 XA Transactions。

MySQL從5.5版本開始支持，SQL Server 2005 開始支持，Oracle 7 開始支持。

其中，XA 是一個兩階段提交協議，該協議分爲如下兩個階段：

第一階段：事務協調器要求每一個涉及到事務的數據庫預提交(precommit)此操做，並反映是否能夠提交.
第二階段：事務協調器要求每一個數據庫提交數據。

其中，若是有任何一個數據庫否決這次提交，那麼全部數據庫都會被要求回滾它們在此事務中的那部分信息。這樣作的缺陷是什麼呢? 咋看之下咱們能夠在數據庫分區之間得到一致性。

若是CAP 定理是對的，那麼它必定會影響到可用性。

若是說系統的可用性表明的是執行某項操做相關全部組件的可用性的和。那麼在兩階段提交的過程當中，可用性就表明了涉及到的每個數據庫中可用性的和。咱們假設兩階段提交的過程當中每個數據庫都具備99.9%的可用性，那麼若是兩階段提交涉及到兩個數據庫，這個結果就是99.8%。根據系統可用性計算公式，假設每月43200分鐘，99.9%的可用性就是43157分鐘, 99.8%的可用性就是43114分鐘，至關於每月的宕機時間增長了43分鐘。

以上，能夠驗證出來，CAP定理從理論上來說是正確的，CAP咱們先看到這裏，等會再接着說。

BASE理論

在分佈式系統中，咱們每每追求的是可用性，它的重要程序比一致性要高，那麼如何實現高可用性呢？前人已經給咱們提出來了另一個理論，就是BASE理論，它是用來對CAP定理進行進一步擴充的。BASE理論指的是：

Basically Available（基本可用）
Soft state（軟狀態）
Eventually consistent（最終一致性）

BASE理論是對CAP中的一致性和可用性進行一個權衡的結果，理論的核心思想就是：咱們沒法作到強一致，但每一個應用均可以根據自身的業務特色，採用適當的方式來使系統達到最終一致性（Eventual consistency）。

有了以上理論以後，咱們來看一下分佈式事務的問題。

分佈式事務

在分佈式系統中，要實現分佈式事務，無外乎那幾種解決方案。

1、兩階段提交（2PC）

和上一節中提到的數據庫XA事務同樣，兩階段提交就是使用XA協議的原理，咱們能夠從下面這個圖的流程來很容易的看出中間的一些好比commit和abort的細節。

兩階段提交這種解決方案屬於犧牲了一部分可用性來換取的一致性。在實現方面，在 .NET 中，能夠藉助 TransactionScop 提供的 API 來編程實現分佈式系統中的兩階段提交，好比WCF中就有實現這部分功能。不過在多服務器之間，須要依賴於DTC來完成事務一致性，Windows下微軟搞的有MSDTC服務，Linux下就比較悲劇了。

另外說一句，TransactionScop 默認不能用於異步方法之間事務一致，由於事務上下文是存儲於當前線程中的，因此若是是在異步方法，須要顯式的傳遞事務上下文。

優勢： 儘可能保證了數據的強一致，適合對數據強一致要求很高的關鍵領域。（其實也不能100%保證強一致）

缺點： 實現複雜，犧牲了可用性，對性能影響較大，不適合高併發高性能場景，若是分佈式系統跨接口調用，目前 .NET 界尚未實現方案。

2、補償事務（TCC）

TCC 其實就是採用的補償機制，其核心思想是：針對每一個操做，都要註冊一個與其對應的確認和補償（撤銷）操做。它分爲三個階段：

Try 階段主要是對業務系統作檢測及資源預留
Confirm 階段主要是對業務系統作確認提交，Try階段執行成功並開始執行 Confirm階段時，默認 Confirm階段是不會出錯的。即：只要Try成功，Confirm必定成功。
Cancel 階段主要是在業務執行錯誤，須要回滾的狀態下執行的業務取消，預留資源釋放。

舉個例子，假入 Bob 要向 Smith 轉帳，思路大概是：
咱們有一個本地方法，裏面依次調用
一、首先在 Try 階段，要先調用遠程接口把 Smith 和 Bob 的錢給凍結起來。
二、在 Confirm 階段，執行遠程調用的轉帳的操做，轉帳成功進行解凍。
三、若是第2步執行成功，那麼轉帳成功，若是第二步執行失敗，則調用遠程凍結接口對應的解凍方法 (Cancel)。

優勢： 跟2PC比起來，實現以及流程相對簡單了一些，但數據的一致性比2PC也要差一些

缺點： 缺點仍是比較明顯的，在2,3步中都有可能失敗。TCC屬於應用層的一種補償方式，因此須要程序員在實現的時候多寫不少補償的代碼，在一些場景中，一些業務流程可能用TCC不太好定義及處理。

3、本地消息表（異步確保）

本地消息表這種實現方式應該是業界使用最多的，其核心思想是將分佈式事務拆分紅本地事務進行處理，這種思路是來源於ebay。咱們能夠從下面的流程圖中看出其中的一些細節：

基本思路就是：

消息生產方，須要額外建一個消息表，並記錄消息發送狀態。消息表和業務數據要在一個事務裏提交，也就是說他們要在一個數據庫裏面。而後消息會通過MQ發送到消息的消費方。若是消息發送失敗，會進行重試發送。

消息消費方，須要處理這個消息，並完成本身的業務邏輯。此時若是本地事務處理成功，代表已經處理成功了，若是處理失敗，那麼就會重試執行。若是是業務上面的失敗，能夠給生產方發送一個業務補償消息，通知生產方進行回滾等操做。

生產方和消費方定時掃描本地消息表，把還沒處理完成的消息或者失敗的消息再發送一遍。若是有靠譜的自動對帳補帳邏輯，這種方案仍是很是實用的。

這種方案遵循BASE理論，採用的是最終一致性，筆者認爲是這幾種方案裏面比較適合實際業務場景的，即不會出現像2PC那樣複雜的實現(當調用鏈很長的時候，2PC的可用性是很是低的)，也不會像TCC那樣可能出現確認或者回滾不了的狀況。

優勢： 一種很是經典的實現，避免了分佈式事務，實現了最終一致性。在 .NET中有現成的解決方案。

缺點： 消息表會耦合到業務系統中，若是沒有封裝好的解決方案，會有不少雜活須要處理。

4、MQ 事務消息

有一些第三方的MQ是支持事務消息的，好比RocketMQ，他們支持事務消息的方式也是相似於採用的二階段提交，可是市面上一些主流的MQ都是不支持事務消息的，好比 RabbitMQ 和 Kafka 都不支持。

以阿里的 RocketMQ 中間件爲例，其思路大體爲：

第一階段Prepared消息，會拿到消息的地址。
第二階段執行本地事務，第三階段經過第一階段拿到的地址去訪問消息，並修改狀態。

也就是說在業務方法內要想消息隊列提交兩次請求，一次發送消息和一次確認消息。若是確認消息發送失敗了RocketMQ會按期掃描消息集羣中的事務消息，這時候發現了Prepared消息，它會向消息發送者確認，因此生產方須要實現一個check接口，RocketMQ會根據發送端設置的策略來決定是回滾仍是繼續發送確認消息。這樣就保證了消息發送與本地事務同時成功或同時失敗。

遺憾的是，RocketMQ並無 .NET 客戶端。有關 RocketMQ的更多消息，你們能夠查看這篇博客

優勢： 實現了最終一致性，不須要依賴本地數據庫事務。

缺點： 實現難度大，主流MQ不支持，沒有.NET客戶端，RocketMQ事務消息部分代碼也未開源。

5、Sagas 事務模型

Saga事務模型又叫作長時間運行的事務（Long-running-transaction）, 它是由普林斯頓大學的H.Garcia-Molina等人提出，它描述的是另一種在沒有兩階段提交的的狀況下解決分佈式系統中複雜的業務事務問題。你能夠在這裏看到 Sagas 相關論文。

咱們這裏說的是一種基於 Sagas 機制的工做流事務模型，這個模型的相關理論目前來講仍是比較新的，以致於百度上幾乎沒有什麼相關資料。

該模型其核心思想就是拆分分佈式系統中的長事務爲多個短事務，或者叫多個本地事務，而後由 Sagas 工做流引擎負責協調，若是整個流程正常結束，那麼就算是業務成功完成，若是在這過程當中實現失敗，那麼Sagas工做流引擎就會以相反的順序調用補償操做，從新進行業務回滾。

好比咱們一次關於購買旅遊套餐業務操做涉及到三個操做，他們分別是預約車輛，預約賓館，預約機票，他們分別屬於三個不一樣的遠程接口。可能從咱們程序的角度來講他們不屬於一個事務，可是從業務角度來講是屬於同一個事務的。

他們的執行順序如上圖所示，因此當發生失敗時，會依次進行取消的補償操做。

由於長事務被拆分了不少個業務流，因此 Sagas 事務模型最重要的一個部件就是工做流或者你也能夠叫流程管理器（Process Manager），工做流引擎和Process Manager雖然不是同一個東西，可是在這裏，他們的職責是相同的。在選擇工做流引擎以後，最終的代碼也許看起來是這樣的

SagaBuilder saga = SagaBuilder.newSaga("trip")
        .activity("Reserve car", ReserveCarAdapter.class) 
        .compensationActivity("Cancel car", CancelCarAdapter.class) 
        .activity("Book hotel", BookHotelAdapter.class) 
        .compensationActivity("Cancel hotel", CancelHotelAdapter.class) 
        .activity("Book flight", BookFlightAdapter.class) 
        .compensationActivity("Cancel flight", CancelFlightAdapter.class) 
        .end()
        .triggerCompensationOnAnyError();

camunda.getRepositoryService().createDeployment() 
        .addModelInstance(saga.getModel()) 
        .deploy();

這裏有一個 C# 相關示例，有興趣的同窗能夠看一下。

優缺點這裏咱們就不說了，由於這個理論比較新，目前市面上尚未什麼解決方案，即便是 Java 領域，我也沒有搜索的太多有用的信息。