本節涉及到一些技術術語：2PC、CAP、BASE、RocketMQ、RabbitMQ、XA、Kafka、TCC

事務

在數據庫系統中，一個事務是指：由一系列數據庫操作組成的一個完整的邏輯過程。例如銀行轉帳，從原賬戶扣除金額，以及向目標賬戶添加金額，這兩個數據庫操作的總和，構成一個完整的邏輯過程，不可拆分。這個過程被稱為一個事務，具有ACID特性。

ACID：是指在數據庫管理系統（DBMS）中，事務(transaction)所具有的四個特性：原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation，又稱獨立性）、持久性（Durability）。
l ?原子性：一個事務(transaction)中的所有操作，要么全部完成，要么全部不完成，不會結束在中間某個環節。事務在執行過程中發生錯誤，會被回滾（Rollback）到事務開始前的狀態，就像這個事務從來沒有執行過一樣。
l ?一致性：在事務開始之前和事務結束以后，數據庫的完整性限制沒有被破壞。
l ?隔離性：當兩個或者多個事務并發訪問（此處訪問指查詢和修改的操作）數據庫的同一數據時所表現出的相互關系。事務隔離分為不同級別，包括讀未提交(Read uncommitted)、讀提交（read committed）、可重復讀（repeatable read）和串行化（Serializable）。
l ?持久性：在事務完成以后，該事務對數據庫所作的更改便持久地保存在數據庫之中，并且是完全的。
?

分布式理論

當我們的單個數據庫的性能產生瓶頸的時候，我們可能會對數據庫進行分區，這里所說的分區指的是物理分區，分區之后可能不同的庫就處于不同的服務器上了，這個時候單個數據庫的ACID已經不能適應這種情況了，而在這種ACID的集群環境下，再想保證集群的ACID幾乎是很難達到，或者即使能達到那么效率和性能會大幅下降，最為關鍵的是再很難擴展新的分區了，這個時候如果再追求集群的ACID會導致我們的系統變得很差，這時我們就需要引入一個新的理論原則來適應這種集群的情況，就是 CAP 原則或者叫CAP定理，那么CAP定理指的是什么呢？

CAP：

CAP原理指的是，一致性(Consistency)可用性(Availability)分區容忍性(Partitiontolerance)這三個要素最多只能同時實現兩點，不可能三者兼顧。這是Brewer教授于2000年提出的，后人也論證了CAP理論的正確性。

l ?一致性（Consistency） ：對于分布式的存儲系統，一個數據往往會存在多份。簡單的說，一致性會讓客戶對數據的修改操作（增/刪/改），要么在所有的數據副本（replica）全部成功，要么全部失敗。即，修改操作對于一份數據的所有副本（整個系統）而言，是原子（atomic）的操作。如果一個存儲系統可以保證一致性，那么則客戶讀寫的數據完全可以保證是最新的。不會發生兩個不同的客戶端在不同的存儲節點中讀取到不同副本的情況。
l ?可用性（Availability） ：可用性很簡單，顧名思義，就是指在客戶端想要訪問數據的時候，可以得到響應。但是注意，系統可用（Available）并不代表存儲系統所有節點提供的數據是一致的。這種情況，我們仍然說系統是可用的。往往我們會對不同的應用設定一個最長響應時間，超過這個響應時間的服務我們仍然稱之為不可用的。
l ?分區容忍性（Partition Tolerance） ：如果你的存儲系統只運行在一個節點上，要么系統整個崩潰，要么全部運行良好。比如，兩個存儲節點之間聯通的網絡斷開（無論長時間或者短暫的），就形成了分區。一般來講，為了提高服務質量，同一份數據放置在不同城市非常正常的。因此節點之間形成分區也很正常。

CAP定理總結

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

·????????一致性(Consistency) ：客戶端知道一系列的操作都會同時發生(生效)

·????????可用性(Availability) ：每個操作都必須以可預期的響應結束

·????????分區容錯性(Partitiontolerance) ：即使出現單個組件無法可用,操作依然可以完成

具體地講在分布式系統中，在任何數據庫設計中，一個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全稱是BasicallyAvailable（基本可用）, Soft-state（軟狀態/柔性事務）, Eventually Consistent（最終一致性）。BASE模型在理論邏輯上是相反于ACID（原子性Atomicity、一致性Consistency、隔離性Isolation、持久性Durability）模型的概念，它犧牲高一致性，獲得可用性和分區容忍性。
?

|?基本可用（Basically Available）。基本可用是指分布式系統在出現故障的時候，允許損失部分可用性，即保證核心可用。電商大促時，為了應對訪問量激增，部分用戶可能會被引導到降級頁面，服務層也可能只提供降級服務。這就是損失部分可用性的體現。

|?軟狀態（Soft-state）。軟狀態是指允許系統存在中間狀態，而該中間狀態不會影響系統整體可用性。分布式存儲中一般一份數據至少會有三個副本，允許不同節點間副本同步的延時就是軟狀態的體現。mysql replication的異步復制也是一種體現。

l ?最終一致性?（Eventually Consistent）。最終一致性是指：經過一段時間以后，更新的數據會到達系統中的所有相關節點。這段時間就被稱之為最終一致性的時間窗口
BASE理論總結

BASE理論是對CAP中的一致性和可用性進行一個權衡的結果，理論的核心思想就是：我們無法做到強一致，但每個應用都可以根據自身的業務特點，采用適當的方式來使系統達到最終一致性（Eventualconsistency）。

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

分布式事務

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

一、兩階段提交（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不太好定義及處理。（在我的理解是，有點try，catch的思想。）

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

本地消息表這種實現方式應該是業界使用最多的，其核心思想是將分布式事務拆分成本地事務進行處理，其基本的設計思想是將遠程分布式事務拆分成一系列的本地事務，這種思路是來源于ebay。我們可以從下面的流程圖中看出其中的一些細節：

基本思路就是：

消息生產方，需要額外建一個消息表，并記錄消息發送狀態。消息表和業務數據要在一個事務里提交，也就是說他們要在一個數據庫里面。然后消息會經過MQ發送到消息的消費方。如果消息發送失敗，會進行重試發送。

消息消費方，需要處理這個消息，并完成自己的業務邏輯。此時如果本地事務處理成功，表明已經處理成功了，如果處理失敗，那么就會重試執行。如果是業務上面的失敗，可以給生產方發送一個業務補償消息，通知生產方進行回滾等操作。

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

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

優點：?一種非常經典的實現，避免了分布式事務，實現了最終一致性。在 .NET中有現成的解決方案。

缺點：?消息表會耦合到業務系統中，如果沒有封裝好的解決方案，會有很多雜活需要處理。

四、MQ 事務消息

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

以阿里的 RocketMQ 中間件為例，其思路大致為：

第一階段Prepared消息，會拿到消息的地址。
第二階段執行本地事務，

第三階段通過第一階段拿到的地址去訪問消息，并修改狀態。

也就是說在業務方法內要想消息隊列提交兩次請求，一次發送消息和一次確認消息。

如果確認消息發送失敗了，RocketMQ會定期掃描消息集群中的事務消息，這時候發現了Prepared消息，它會向消息發送者確認，所以生產方需要實現一個check接口，

RocketMQ會根據發送端設置的策略來決定是回滾還是繼續發送確認消息。這樣就保證了消息發送與本地事務同時成功或同時失敗。

?

總結

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

介紹個場景：

4、分布式事務的應用場景

4.1、支付

最經典的場景就是支付了，一筆支付，是對買家賬戶進行扣款，同時對賣家賬戶進行加錢，這些操作必須在一個事務里執行，要么全部成功，要么全部失敗。而對于買家賬戶屬于買家中心，對應的是買家數據庫，而賣家賬戶屬于賣家中心，對應的是賣家數據庫，對不同數據庫的操作必然需要引入分布式事務。

4.2、在線下單

買家在電商平臺下單，往往會涉及到兩個動作，一個是扣庫存，第二個是更新訂單狀態，庫存和訂單一般屬于不同的數據庫，需要使用分布式事務保證數據一致性。

5、常見的分布式事務解決方案

5.1、基于XA協議的兩階段提交

XA是一個分布式事務協議，由Tuxedo提出。XA中大致分為兩部分：事務管理器和本地資源管理器。其中本地資源管理器往往由數據庫實現，比如Oracle、DB2這些商業數據庫都實現了XA接口，而事務管理器作為全局的調度者，負責各個本地資源的提交和回滾。XA實現分布式事務的原理如下：

總的來說，XA協議比較簡單，而且一旦商業數據庫實現了XA協議，使用分布式事務的成本也比較低。但是，XA也有致命的缺點，那就是性能不理想，特別是在交易下單鏈路，往往并發量很高，XA無法滿足高并發場景。XA目前在商業數據庫支持的比較理想，在mysql數據庫中支持的不太理想，mysql的XA實現，沒有記錄prepare階段日志，主備切換回導致主庫與備庫數據不一致。許多nosql也沒有支持XA，這讓XA的應用場景變得非常狹隘。

5.2、消息事務+最終一致性

所謂的消息事務就是基于消息中間件的兩階段提交，本質上是對消息中間件的一種特殊利用，它是將本地事務和發消息放在了一個分布式事務里，保證要么本地操作成功并且對外發消息成功，要么兩者都失敗，開源的RocketMQ就支持這一特性，具體原理如下：

1、A系統向消息中間件發送一條預備消息
2、消息中間件保存預備消息并返回成功
3、A執行本地事務
4、A發送提交消息給消息中間件

通過以上4步完成了一個消息事務。對于以上的4個步驟，每個步驟都可能產生錯誤，下面一一分析：

·????????步驟一出錯，則整個事務失敗，不會執行A的本地操作

·????????步驟二出錯，則整個事務失敗，不會執行A的本地操作

·????????步驟三出錯，這時候需要回滾預備消息，怎么回滾？答案是A系統實現一個消息中間件的回調接口，消息中間件會去不斷執行回調接口，檢查A事務執行是否執行成功，如果失敗則回滾預備消息

·????????步驟四出錯，這時候A的本地事務是成功的，那么消息中間件要回滾A嗎？答案是不需要，其實通過回調接口，消息中間件能夠檢查到A執行成功了，這時候其實不需要A發提交消息了，消息中間件可以自己對消息進行提交，從而完成整個消息事務

基于消息中間件的兩階段提交往往用在高并發場景下，將一個分布式事務拆成一個消息事務（A系統的本地操作+發消息）+B系統的本地操作，其中B系統的操作由消息驅動，只要消息事務成功，那么A操作一定成功，消息也一定發出來了，這時候B會收到消息去執行本地操作，如果本地操作失敗，消息會重投，直到B操作成功，這樣就變相地實現了A與B的分布式事務。原理如下：

雖然上面的方案能夠完成A和B的操作，但是A和B并不是嚴格一致的，而是最終一致的，我們在這里犧牲了一致性(不是某一時刻就立刻一致的)，換來了性能的大幅度提升。當然，這種玩法也是有風險的，如果B一直執行不成功，那么一致性會被破壞，具體要不要玩，還是得看業務能夠承擔多少風險。

舉個例子，比如A訂單系統，B為庫存系統，正常是下單，減庫存。那么如果按照二階段是，如果庫存系統因為并發而發生回滾，那么A系統也一并回滾，這樣的可用性就很低。

如果加入這個消息中間件，則認為A系統事務成功了，B系統也會事務成功，B不成功則再發送直到它成功即可。分布式事務是A下單，B減庫存，把分布式事務分為，A下單的本地事務+發送消息，然后B再減庫存的本地事務。

5.3、TCC編程模式

所謂的TCC編程模式，也是兩階段提交的一個變種。TCC提供了一個編程框架，將整個業務邏輯分為三塊：Try、Confirm和Cancel三個操作。以在線下單為例，Try階段會去扣庫存，Confirm階段則是去更新訂單狀態，如果更新訂單失敗，則進入Cancel階段，會去恢復庫存。總之，TCC就是通過代碼人為實現了兩階段提交，不同的業務場景所寫的代碼都不一樣，復雜度也不一樣，因此，這種模式并不能很好地被復用。

6、總結

分布式事務，本質上是對多個數據庫的事務進行統一控制，按照控制力度可以分為：不控制、部分控制和完全控制。不控制就是不引入分布式事務，部分控制就是各種變種的兩階段提交，包括上面提到的消息事務+最終一致性、TCC模式，而完全控制就是完全實現兩階段提交。部分控制的好處是并發量和性能很好，缺點是數據一致性減弱了，完全控制則是犧牲了性能，保障了一致性，具體用哪種方式，最終還是取決于業務場景。作為技術人員，一定不能忘了技術是為業務服務的，不要為了技術而技術，針對不同業務進行技術選型也是一種很重要的能力！

總結

以上是生活随笔為你收集整理的数据库：分布式事务的解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。