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

來源：https://www.cnblogs.com/savorboard/p/7679902.html
作者：Savorboard

前言

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

接下來還是開始我們今天的話題，說說分散式事務，或者說是我眼中的分散式事務，因為每個人可能對其的理解都不一樣。

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

資料庫事務

在說分散式事務之前，我們先從資料庫事務說起。
資料庫事務可能大家都很熟悉，在開發過程中也會經常使用到。但是即使如此，可能對於一些細節問題，很多人仍然不清楚。比如很多人都知道資料庫事務的幾個特性：原子性(Atomicity
)、一致性( Consistency )、隔離性或獨立性(
Isolation)和持久性(Durabilily)，簡稱就是ACID。但是再往下比如問到隔離性指的是什麼的時候可能就不知道了，或者是知道隔離性是什麼但是再問到資料庫實現隔離的都有哪些級別，或者是每個級別他們有什麼區別的時候可能就不知道了。

本文並不打算介紹這些資料庫事務的這些東西，有興趣可以搜索一下相關資料。不過有一個知識點我們需要瞭解，就是假如資料庫在提交事務的時候突然斷電，那麼它是怎麼樣恢復的呢？
為什麼要提到這個知識點呢？
因為分散式系統的核心就是處理各種異常情況，這也是分散式系統複雜的地方，因為分散式的網路環境很複雜，這種“斷電”故障要比單機多很多，所以我們在做分散式系統的時候，最先考慮的就是這種情況。這些異常可能有
機器宕機、網路異常、消息丟失、消息亂序、數據錯誤、不可靠的TCP、存儲數據丟失、其他異常等等...

我們接著說本地事務資料庫斷電的這種情況，它是怎麼保證數據一致性的呢？我們使用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）。

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

分散式事務

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

一、兩階段提交（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的更多消息，大家可以查看

這篇博客

優點： 實現了最終一致性，不需要依賴本地資料庫事務。

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

五、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 領域，我也沒有搜索的太多有用的信息。

分散式事務解決方案：CAP

上面介紹的那些分散式事務的處理方案你在其他地方或許也可以看到，但是並沒有相關的實際代碼或者是開源代碼，所以算不上什麼乾貨，下麵就放乾貨了。

在 .NET
領域，似乎沒有什麼現成的關於分散式事務的解決方案，或者說是有但未開源。具筆者瞭解，有一些公司內部其實是有這種解決方案的，但是也是作為公司的一個核心產品之一，並未開源...

鑒於以上原因，所以博主就打算自己寫一個並且開源出來，所以從17年初就開始做這個事情，然後花了大半年的時間在一直不斷完善，就是下麵這個 CAP。

Github CAP ：這裡的 CAP 就不是 CAP 理論了，而是一個
.NET 分散式事務解決方案的名字。

詳細介紹：

http://www.cnblogs.com/savorboard/p/cap.html

相關文檔：

http://www.cnblogs.com/savorboard/p/cap-document.html

誇張的是，這個解決方案是具有可視化界面（Dashboard）的，你可以很方面的看到哪些消息執行成功，哪些消息執行失敗，到底是發送失敗還是處理失敗，一眼便知。

最誇張的是，這個解決方案的可視化界面還提供了 實時動態圖表
，這樣不但可以看到實時的消息發送及處理情況，連當前的系統處理消息的速度都可以看到，還可以看到過去24小時內的歷史消息吞吐量。

最最誇張的是，這個解決方案的還幫你集成了 Consul 做分散式節點發現和註冊還有心跳檢查，你隨時可以看到其他的節點的狀況。

最最最誇張的是，你以為你看其他節點的數據要登錄到其他節點的Dashboard控制台看？錯了，你隨便打開其中任意一個節點的Dashboard，點一下就可以切換到你想看的節點的控制台界面了，就像你看本地的數據一樣，他們是完全去中心化的。

你以為這些就夠了？不，遠遠不止：

• CAP 同時支持 RabbitMQ，Kafka 等消息隊列
• CAP 同時支持 SQL Server, MySql, PostgreSql 等資料庫
• CAP Dashboard 同時支持中文和英文界面雙語言，媽媽再也不用擔心我看不懂了
• CAP 提供了豐富的介面可以供擴展，什麼序列化了，自定義處理了，自定義發送了統統不在話下
• CAP 基於MIT開源，你可以儘管拿去做二次開發。（記得保留MIT的License）

這下你以為我說完了？ 不！

你完全可以把 CAP 當做一個 EventBus 來使用，CAP具有優秀的消息處理能力，不要擔心瓶頸會在CAP，那是永遠不可能，
因為你隨時可以在配置中指定CAP處理的消息使用的進程數， 只要你的資料庫配置足夠高...

說了這麼多，口乾舌燥的，你不 Star 一下給個精神上的支持說不過去吧？ ^_

2號傳送門： https://github.com/dotnetcore/CAP
不 Star 也沒關係，我選擇原諒你~

總結

通過本文我們瞭解到兩個分散式系統的理論，他們分別是CAP和BASE
理論，同時我們也總結並對比了幾種分散式分解方案的優缺點，分散式事務本身是一個技術難題，是沒有一種完美的方案應對所有場景的，具體還是要根據業務場景去抉擇吧。
然後我們介紹了一種基於本地消息的的分散式事務解決方案CAP。

如果你覺得本篇文章對您有幫助的話，感謝您的【推薦】。

如果你對 .NET Core 有興趣的話可以關註我，我會定期的在博客分享我的學習心得。

推薦閱讀

• 利用 ShardingSphere-JDBC 實現分庫分表實踐
• Spring Boot 構建多租戶 SaaS 平臺核心技術指南
• Redis 緩存和MySQL數據一致性方案詳解
• Nginx 限流配置
• 深入探秘 Netty、Kafka中的零拷貝技術！

學習資料分享

12 套 微服務、Spring Boot、Spring Cloud 核心技術資料，這是部分資料目錄：

• Spring Security 認證與授權
• Spring Boot 項目實戰（中小型互聯網公司後臺服務架構與運維架構）
• Spring Boot 項目實戰（企業許可權管理項目））
• Spring Cloud 微服務架構項目實戰（分散式事務解決方案）
• ...

公眾號後臺回覆arch028獲取資料：：