前言

分布式的 CAP 理論應該是人盡皆知了，它描述了一致性（C）、可用性（A）、分區容錯性（P）的一系列權衡。

很多時候，我們要在一致性和可用性之間權衡，而分布式事務，就是在這個大的前提下，盡可能的達成一致性的要求。

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

“如何在微服務中實現分布式事務？”一般在被問到這樣的問題時，我都會回答“要盡量避免使用分布式事務”，這也是 Martin Fowler 所推薦的。

但現實總是殘酷的，拆分了微服務之后，分布式事務是非常硬核的需求，是繞不開的，我們依然要想辦法搞定它。

但分布式環境錯綜復雜，還伴隨著網絡狀況產生的超時，如何讓事務達到一致性的狀態，難度很大。

分布式事務，由一系列小的子事務組成。這些子事務，同大的分布式事務一樣，同樣要遵循 ACID 的原則。

在一致性這個屬性上，根據達到一致性之前所存在的時間，又分為強一致性和最終一致性（BASE）。

注意，對于子事務，這里有個小小的誤解。并不是只有和數據庫打交道的操作，才叫做事務。

在微服務環境下，如果你通過 RPC 調用了另外一個遠程接口，并造成了相關數據狀態的變化，這個 RPC 接口，也叫做事務。

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

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

一階段提交（1PC）

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

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

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

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

兩階段提交（2PC）

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

| 重要參與者

如下：

• 協調者（coordinator），也就是我們需要自建事務管理器，通常在整個系統中只有一個
• 事務參與者（participants），就是指的我們所說的資源，通常情況下會有多個，否則也稱不上分布式事務了

| 過程

廣義上的 2PC（two phase commit），有哪兩階段呢？

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

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

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

二階段提交其實非常容易理解。你可以把每個參與者的執行，想象成正常的 SQL 更新語句。

它們一直掛在那里等待，直到協調者給出確切的 commit 或者 rollback 消息，才會正常往下執行。

| 問題

如下：

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

對于第三點，我們舉個例子。比如你的 commit-request 階段全部返回了 yes，然后協調者發送了 commit 指令。

但這時候，有一臺服務器 A 宕機了，無法執行這個 commit。這時候，我們的 client 也會收到成功的消息。

A 機器重啟之后，要有能力來恢復、繼續執行 commit 指令，這些都是工程上必須要處理的。

| 框架

2PC 也叫做 XA 事務，大多數數據庫如 MySQL，都支持 XA 協議。在 Java 中，JTA（不是什么 JPA 哦）是 XA 協議的實現。

Spring 也有 JTA 的事務管理器：

• Atomikos、bitronix 實現了 JTA，它們只需要提供 jar 包就可以了。實現了 XA 協議的數據庫或者消息隊列，已經能夠具備了準備、提交、回滾的各種能力
• 使用在 seata 等框架，需要啟動一個獨立的 seata 服務協調者節點。seata 使用的 AT，借助于外部事務管理器，概念與 XA 類似

三階段提交（3PC）

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

| 重要參與者

3PC 和 2PC 是一樣的。

| 過程

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 階段，如果超時還會繼續執行下去。但不論怎樣，整個事務并不會一直等待下去。

| 問題

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

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

TCC

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

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

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

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

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

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

如上圖，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 里，否則它根據啥回滾呢？

| 問題

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

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

| 框架

ByteTCC、tcc-transaction、seata 等。

SAGA

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

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

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

比如，我們把事務 T，拆分成了 T1，T2，T3，T4。那么我們就必須為這些子事務，提供相應的執行邏輯和補償邏輯。

沒錯，和 TCC 一樣，不過比 TCC 少了一步 Try 動作，同樣要求這些操作是冪等的。

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

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

上圖是 rob vettor 所繪制的一個典型的 SAGA 事務拆分圖。在圖中，黑色的線為正常業務流程，紅色的線為補償業務流程。

這是一個簡單的電子商務結賬流程，整個交易跨了 5 個微服務，可以說是非常大的長事務了。

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

| 問題

那問題就有意思多了：

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

| 框架

在《微服務架構設計模式》的第四章中，說明了 SAGA 的具體使用示例，現在網絡上的大多數文章都來自于此。

但據我所知，使用 SAGA 的互聯網公司并不是很多，倒是使用 TCC 的比較多一些（可能是遇到的分布式事務都不是長事務）。

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

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

設計完畢之后，就可以導出為 JSON 文件，解析之后可以寫入到數據庫中。bytetcc 雖然叫 tcc，它也支持 SAGA。

| SAGA vs TCC

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

下面簡單的對比一下：

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

本地消息表

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

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

下面我來描述一下這個過程：

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

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

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

| 問題

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

• 需要開發專用的代碼，與業務耦合在一起，無法完成抽象的框架
• 本地消息表需要寫數據庫，如果數據庫本身的 I/O 已經比較高了，它會增加數據庫的壓力

最大努力補償

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

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

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

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

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

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

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

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

總結

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

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

在互聯網公司中，由于高并發量的訴求，在實際應用中，相對于強事務，大家普遍選用軟事務進行業務處理。 使用最多的，就是 TCC、SAGA、本地消息表等解決方案。

SAGA 應對長事務特別拿手，但隔離性稍差； TCC 一直性好并發高，但需要較多編碼； 本地消息表應用場景有限，耦合業務不能復用。 各種解決方案都有它的利弊，一定要結合使用場景進行選擇。

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

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