[[428152]]

本文轉載自微信公眾號「小姐姐味道」，作者小姐姐養的狗  。轉載本文請聯系小姐姐味道公眾號。

分布式的CAP理論應該是人盡皆知了，它描述了一致性(C)、可用性(A)、分區容錯性(P)的一系列權衡。很多時候，我們要在一致性和可用性之間權衡，而分布式事務，就是在這個大的前提下，盡可能的達成一致性的要求。

目標很小，問題很大，做法也各有不同。

“如何在微服務中實現分布式事務?”一般在被問到這樣的問題時，我都會回答“要盡量避免使用分布式事務”，這也是Martin Fowler所推薦的。但現實總是殘酷的，拆分了微服務之后，分布式事務是非常硬核的需求，是繞不開的，我們依然要想辦法搞定它。但分布式環境錯綜復雜，還伴隨著網絡狀況產生的超時，如何讓事務達到一致性的狀態，難度很大。

分布式事務，由一系列小的子事務組成。這些子事務，同大的分布式事務一樣，同樣要遵循ACID的原則。在一致性這個屬性上，根據達到一致性之前所存在的時間，又分為強一致性和最終一致性(BASE)。

注意，對于子事務，這里有個小小的誤解。并不是只有和數據庫打交道的操作，才叫做事務。在微服務環境下，如果你通過RPC調用了另外一個遠程接口，并造成了相關數據狀態的變化，這個RPC接口，也叫做事務。

所以，在分布式事務中，我們把這些子事務涉及到的操作，叫做資源。當操作能正常完成的時候，根本不需要什么額外處理。事務主要處理的是發生異常之后的流程。

下面，我們就來看一下常見的分布式事務解決方案。

1. 一階段提交(1PC)

先來看一下最簡單的事務提交情況。

如果你的業務，只有一個資源需要協調，那么它可以直接提交。比如，你使用了一個數據庫，那么就可以直接使用begin，commit等指令完成事務提交。

在Spring中，通過注解，就可以完成這樣的事務。如果發生了嵌套事務，它的實現方式，本質上，是通過ThreadLocal向下傳遞的。所以如果你的應用中有子線程相關的事務需要管理，它辦不到。

我們再來看分布式事務。所謂的分布式事務，就是協調2個或者多個資源，達到共同提交或者共同失敗的效果，也就是分布式的ACID。

2. 兩階段提交(2PC)

在一階段提交的概念擴展下，最簡單的分布式事務解決方案，就是二階段提交。二階段提交不是指有兩個參與資源，而是說有兩個分布式的協調階段，它可能有多個資源需要協調。

2.1 重要參與者

協調者(coordinator)，也就是我們需要自建事務管理器，通常在整個系統中只有一個。

事務參與者(participants)，就是指的我們所說的資源，通常情況下會有多個，否則也稱不上分布式事務了。

2.2 過程

廣義上的2PC(two phase commit)，有哪兩階段呢?

• client 分布式事務發起者
• commit-request/voting 準備階段
• commit/rollback 提交或者回滾

準備階段，也叫做voting階段。所謂的voting，就是參與者告知協調者，自己的資源到底是能夠提交(代表它準備好了)，還是取消本次事務(比如發生異常)。

這個投票比較有意思，只要有一個參與者返回了false，本次事務就需要終止，然后執行rollback。只有全票通過，才會正常commit。協調者將這個結果，周知所有參與者的這個過程，就是二階段。

二階段提交其實非常容易理解。你可以把每個參與者的執行，想象成正常的SQL更新語句。它們一直掛在那里等待，直到協調者給出確切的commit或者rollback消息，才會正常往下執行。

2.3 問題

• 阻塞問題。兩階段提交最大的問題，就是它是一個阻塞的協議，效率低。如果協調器永久失敗，一些參與者，將永遠無法完成它的事務
• 單點故障問題。由于協調者在整個環節中有著非常重要的作用，所以一旦它發生了SPOF，整個系統將變的不可用，這是不能忍受的
• 事務完整性問題。在某些情況下，比如協調者發送commit指令后，發生異常，有一部分執行成功了，會造成整個事務不一致。因為能不能提交，第一階段就決定了，第二階段只是通知而已，你就是死也要給我提交
• 并不是所有的資源都支持2PC(或者XA)

對于第三點，我們舉個例子。比如你的commit-request階段全部返回了yes，然后協調者發送了commit指令。但這時候，有一臺服務器A宕機了，無法執行這個commit。這時候，我們的client也會收到成功的消息。A機器重啟之后，要有能力來恢復、繼續執行commit指令，這些都是工程上必須要處理的。

2.4 框架

2PC也叫做XA事務，大多數數據庫如MySQL，都支持XA協議。在Java中，JTA(不是什么JPA哦)是XA協議的實現。Spring也有JTA的事務管理器。

Atomikos、bitronix實現了JTA，它們只需要提供jar包就可以了。實現了XA協議的數據庫或者消息隊列，已經能夠具備了準備、提交、回滾的各種能力。

使用在seata等框架，需要啟動一個獨立的seata服務協調者節點。seata使用的AT，借助于外部事務管理器，概念與XA類似。

3. 三階段提交(3PC)

相比較二階段提交，三階段提交最典型的特點是加入了超時機制。當然，3階段證明了它有三個階段，這個差別更顯著。它本質上只是2PC的一些改進，所以身上完全充滿了2PC的影子。

3.1 重要參與者

3PC和2PC是一樣的。

3.2 過程

3PC比2PC多了一個步驟，那就是詢問階段。

• CanCommit 詢問階段
• PreCommit 準備階段
• DoCommit 提交階段

提交階段，無非就是發送個commit或者rollback指令，重要的處理還是在準備階段，3PC把它一拆為2。

注意下面這個對應關系哦，2PC和3PC都有一個準備階段，但它們的作用是不同的。

3PC     2PC 
CanCommit   commit-request/voting 
PreCommit  
DoCommit    commit 

3PC的詢問階段，對應的才是2PC的準備階段，都是ask一下參與者是否準備好了，但執行過程會有一些區別。

為什么要這么做?因為2PC有效率問題。2PC的執行過程是阻塞的，一個資源在進入準備階段之后，必須等待所有的資源準備完畢才能進行下一步，在這個過程中，它們對全局一無所知。

比如，有ABCDE等5個參與者，E其實是一個有問題的參與者資源。但2PC每次都會執行ABCD的預提交，當詢問到E的時候，發現是有問題的，再依次執行ABCD等參與者的rollback。在這種情況下，ABCD執行了無用的事務預處理和rollback，是非常浪費資源的。

3PC通過拆分這個詢問階段，在確保所有參與者建康良好的情況下，才會發起真正的事務處理，在效率和容錯性上更勝一籌。從概率上來講，由于commit之前粒度變小了，commit階段出問題的幾率就變小，能省下不少事。

另外，3PC引入了超時機制。在PreCommit階段，如果超時，就認為失敗;而在DoCommit階段，如果超時還會繼續執行下去。但不論怎樣，整個事務并不會一直等待下去。

3.3 問題

3PC理論上是比較優秀的，還能夠避免阻塞問題，但它多了一次網絡通信。如果參與者的數量比較多，網絡質量比較差的情況下，這個開銷非常可觀。它的實現也比較復雜，在實際應用中，是不太多的。

3PC也并不是完美的，因為PreCommit階段和DoCommit也并不是原子的，和2PC類似，依然存在一致性問題。

4. TCC

TCC是柔性事務，而上面介紹的都是剛性事務。有時候，一個技術問題，可以通過業務建模來實現。

2PC和3PC在概念上看起來雖然簡單，但放在分布式環境中，考慮各種超時和宕機問題，如果考慮的周全，那可真是要了老命。

2PC的框架還是比較多的，但3PC全網找了個遍，發現有名的實現幾乎沒有。

不要傷心，我們有更容易理解，更加直觀的分布式事務。那就是TCC，2007年的老古董。

TCC就是大名鼎鼎的補償事務，是互聯網環境最常用的分布式事務。它的核心思想是：為每一個操作，都準備一個確認動作和相應的補償動作，一共3個方法。

與其靠數據庫，不如靠自己的代碼!2PC，3PC，都和數據庫綁的死死的，TCC才是碼農的最愛(意思就是說，你要多寫代碼)。

image-20210914162640227.png

如圖，TCC同樣分為三個階段，但非常的粗暴!

• try 嘗試階段 嘗試鎖定資源
• confirm 確認階段 嘗試將鎖定的資源進行提交
• cancel 取消階段 其中某個環節執行失敗，將發起事務取消動作

看起來這三個階段，是2階段提交的一種?完全不是。但它們的過程可以比較一下。

TCC     2PC 
Try     業務邏輯 
Confirm    commit-request/voting + commit 
Cancel     rollback 

從上面可以看出來，2PC是一種對事務過程的劃分，而TCC是對正常情況的提交和異常情況的補償。相對于傳統的代碼，try和confirm兩者加起來，才是真正的業務邏輯。

TCC是非常容易理解的，但它有一個大的前提，就是這三個動作必須都是冪等的，對業務有一定的要求。拿資金轉賬來說，try就是凍結金額;confirm就是完成扣減;cancel就是解凍，只要對應的訂單號是一直的，多次執行也不會有任何問題。

由于TCC事務的發起方，直接在業務節點即可完成，和TCC的代碼在同一個地方。所以，TCC并不需要一個額外的協調者和事務處理器，它存放在本地表或者資源中即可。

是的，它也要記錄一些信息，哪怕是HashMap里，否則它根據啥回滾呢?

4.1 問題

TCC事務，需要較多的編碼，以及正確的try和confirm劃分。由于沒有中心協調器，不需要阻塞，TCC的并發量較高，被互聯網業務廣泛應用。

團隊要有能力設計TCC接口，將其拆分成正確的Try和Confirm階段，實現業務邏輯的分級。

4.2 框架

ByteTCC、tcc-transaction、seata等。

5. SAGA

SAGA也是一個柔性事務。

saga的歷史更久遠，要追溯到1987年的一篇論文，可以說是瓶舊酒。它主要處理的是長活事務，但它不保證ACID，只保證最終一致性。

所謂長活事務，可以被分解成交錯運行的子事務，它通過消息，來協調一系列的本地子事務，來達到最終的一致性。

我們可以把SAGA編排器，想象成一個狀態機。每當處理完一條消息，它就能夠知道要執行的下一條消息(子事務)。

比如，我們把事務T，拆分成了T1，T2，T3，T4。那么我們就必須為這些子事務，提供相應的執行邏輯和補償邏輯。沒錯，和TCC一樣，不過比TCC少了一步Try動作，同樣要求這些操作是冪等的。

你瞧瞧，其實SAGA的概念很好理解，你就按照正常的業務邏輯去執行就行了。只不過如果在任何一步發生了異常，就要把前面所提交的數據全部回滾(補償)。唯一特殊的是，它通常是通過消息驅動來完成事務運轉的。

如果你非要追求它的本質，那就是SAGA和TCC一樣，都是先記錄執行軌跡，然后通過不斷地重試達到最終狀態。

上圖是rob vettor所繪制的一個典型的SAGA事務拆分圖。在圖中，黑色的線為正常業務流程，紅色的線為補償業務流程。這是一個簡單的電子商務結賬流程，整個交易跨了5個微服務，可以說是非常大的長事務了。

可以看到，這樣的事務流轉，靠文字描述已經是不好理解了，所以SAGA通常會配備一個流程編輯器，直接來把事務編排的過程可視化。

5.1 問題

那問題就有意思多了。

• 嵌套問題。SAGA只允許兩層嵌套，因為靠消息流轉本來就非常復雜了，嵌套層次深在性能和時序上都不允許。
• 如果你的事務包含很多子事務，那么很有可能在某個階段就執行失敗了。但如果補償操作也發生問題了呢?極端情況下，需要人工參與。在很多時候，需要記錄日志(saga log)來配合完成
• 由于這些小事務并不是同時提交的，所以在執行的過程中，會產生臟數據，這和數據庫的read uncommited的概念是一樣的

5.2 框架

在《微服務架構設計模式》的第四章中，說明了SAGA的具體使用示例，現在網絡上的大多數文章都來自于此。但據我所知，使用SAGA的互聯網公司并不是很多，倒是使用TCC的比較多一些(可能是遇到的分布式事務都不是長事務)。

seata同樣提供了SAGA的方式，主要使用的是狀態機驅動的編排模式。為了支持事務的編排，seata提供了一個專用的流程編輯器(在線)。

http://seata.io/saga_designer/index.html 

設計完畢之后，就可以導出為JSON文件，解析之后可以寫入到數據庫中。

bytetcc雖然叫tcc，它也支持SAGA。

5.3 SAGA vs TCC

上面也提到，我在平常工作中，用到TCC比SAGA更多一些，也是由于業務場景確定的。下面簡單的對比一下。

• 開發難度。TCC的開發難度是比SAGA要高的，因為它需要處理Try階段來凍結資源，而SAGA是直接執行本地事務
• 臟讀問題。TCC不存在臟讀，因為try階段并不影響數據;SAGA會在小事務之間，或者cancel之間出現臟讀
• 效率問題。TCC無論成功失敗，都需要和參與方交互兩次;SAGA在正常情況下交互一次，異常情況下交互兩次，所以效率要高
• 業務流程。TCC適合少量的分布式事務流程，否則寫起來就是噩夢;SAGA適合業務流程長，參與方多的業務，或者遺留系統等無法改造成TCC的業務
• 手段。TCC是通過業務建模手段解決技術問題;SAGA是通過技術手段解決事務編排

6. 本地消息表

本地消息表的使用場景比較局限，它要靠MQ去實現，它解決的是數據庫事務和MQ之間的事務問題。

如圖，有一個分布式事務，在正常落庫之后，需要通過MQ來協調后續業務的執行。但是，寫DB和寫MQ，是無法達成一致性的，就需要加入一個本地消息表來緩存發送到MQ的狀態。下面我來描述一下這個過程。

• 1.1 正常寫入數據庫
• 1.2 在寫入數據庫的同時，寫入一張本地消息表。這張表，用來記錄MQ消息處理的狀態，可以有發送中和已完成兩種狀態。由于消息表和正常的業務表在一個DB中，所以可以達成本地事務，確保同時完成
• 2 寫入消息表成功之后，可以異步發送MQ消息，且不用關心投遞是否成功
• 3 后續業務訂閱MQ消息。消費成功之后，將會把執行成功的狀態，再通過MQ來發送。本地業務訂閱這個執行狀態，并把消息表中對應的記錄狀態，改為已完成;如果消費失敗，則不做過多處理
• 4 存在一個定時任務，持續掃描本地消息表中，狀態為發送中的消息(注意延時)，并再次把這些消息發送到MQ，重復2的過程

通過這樣的循環，就可以達到本地DB和MQ消費者狀態的一致性，完成最終一致性的分布式事務。

可以看到，我們有重發MQ的過程，所以這種模式要求消費者也要實現冪等的功能，避免重復對業務產生影響。

6.1 問題

使用本地消息表方案的系統還是挺多的，但它的弊端也顯而易見。

需要開發專用的代碼，與業務耦合在一起，無法完成抽象的框架

本地消息表需要寫數據庫，如果數據庫本身的I/O已經比較高了，它會增加數據庫的壓力

7. 最大努力補償

最大努力補償，是一種衰減式的補償機制。

拿個最簡單的例子來說吧。如果你是微信支付的接入方，微信支付成功之后，它會將支付結果推送到你指定的接口。

微信支付+你的支付結果處理，就可以算是一個大的分布式事務。涉及到微信的系統還有你的自有系統。

如果你的系統一直處理不成功，那么微信支付就會一直不停的重試。這就叫最大努力補償，用在系統內和系統間都是可以的。

但也不能無限的重試，重試的間隔通常會隨著時間衰減。常用的衰減策略有。

messageDelayLevel = 1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h 

上面的公式，意味著如果一直無法處理成功，將在1s...，最大2小時后重試。如果還不成功，就只能進入人工處理通道。

最大努力補償只是一種思想，實際的應用有多種方式。比如，我首先將事務落地到消息隊列，然后依靠消息隊列的重試機制，來達到最大努力補償的效果，這些都是可行的方案。

8. 總結

我們在文中，從本地事務談起，分別聊到了2PC、3PC、TCC、SAGA、本地消息表、最大努力補償等，也了解到了各種解決方案的一些應用場景和解決方式。

分布式事務框架，在這些理論基礎上，都進行了或多或少的修訂，也有不少創新。比如LCN框架(lock，confirm，notify)，就抽象出了控制方和發起方的概念，感興趣的可以自行了解。

在互聯網公司中，由于高并發量的訴求，在實際應用中，相對于強事務，大家普遍選用軟事務進行業務處理。使用最多的，就是TCC、SAGA、本地消息表等解決方案。SAGA應對長事務特別拿手，但隔離性稍差;TCC一直性好并發高，但需要較多編碼;本地消息表應用場景有限，耦合業務不能復用。各種解決方案都有它的利弊，一定要結合使用場景進行選擇。

在框架方面，阿里的seata(早些年叫fescar)，已經得到了廣泛應用，XA、TCC、SAGA等模式都支持，如果你需要這方面的功能，可以集成嘗試一下。

希望看完本文之后，再次碰到“如何在微服務中實現分布式事務?”這種問題，除了回答“要盡量避免使用分布式事務”，你還可以找到確實可行的解決方案。 

作者簡介：小姐姐味道 (xjjdog)，一個不允許程序員走彎路的公眾號。聚焦基礎架構和Linux。十年架構，日百億流量，與你探討高并發世界，給你不一樣的味道。