分布式事務解決方案，中間件 Seata 的設計原理詳解

作者：張乘輝

前言

在微服務架構體系下，我們可以按照業務模塊分層設計，單獨部署，減輕了服務部署壓力，也解耦了業務的耦合，避免了應用逐漸變成一個龐然怪物，從而可以輕松擴展，在某些服務出現故障時也不會影響其它服務的正常運行。總之，微服務在業務的高速發展中帶給我們越來越多的優勢，但是微服務并不是十全十美，因此不能盲目過度濫用，它有很多不足，而且會給系統帶來一定的復雜度，其中伴隨而來的分布式事務問題，是微服務架構體系下必然需要處理的一個痛點，也是業界一直關注的一個領域，因此也出現了諸如 CAP 和 BASE 等理論。

在今年年初，阿里開源了一個分布式事務中間件，起初起名為 Fescar，后改名為 Seata，在它開源之初，我就知道它肯定要火，因為這是一個解決痛點的開源項目，Seata 一開始就是沖著對業務無侵入與高性能方向走，這正是我們對解決分布式事務問題迫切的需求。

分布式事務解決的方案有哪些？

目前分布式事務解決的方案主要有對業務無入qin和有入qin的方案，無入qin方案主要有基于數據庫 XA 協議的兩段式提交（2PC）方案，它的優點是對業務代碼無入qin，但是它的缺點也是很明顯：必須要求數據庫對 XA 協議的支持，且由于 XA 協議自身的特點，它會造成事務資源長時間得不到釋放，鎖定周期長，而且在應用層上面無法干預，因此它性能很差，它的存在相當于七傷拳那樣“傷人七分，損己三分”，因此在互聯網項目中并不是很流行這種解決方案。

為了這個彌補這種方案帶來性能低的問題，大佬們又想出了很多種方案來解決，但這無一例外都需要通過在應用層做手腳，即入qin業務的方式，比如很出名的 TCC 方案，基于 TCC 也有很多成熟的框架，如 ByteTCC、tcc-transaction 等。以及基于可靠消息的最終一致性來實現，如 RocketMQ 的事務消息。

入qin代碼的方案是基于現有情形“迫不得已”才推出的解決方案，實際上它們實現起來非常不優雅，一個事務的調用通常伴隨而來的是對該事務接口增加一系列的反向操作，比如 TCC 三段式提交，提交邏輯必然伴隨著回滾的邏輯，這樣的代碼會使得項目非常臃腫，維護成本高。

Seata 各模塊之間的關系

針對上面所說的分布式事務解決方案的痛點，那很顯然，我們理想的分布式事務解決方案肯定是性能要好而且要對業務無入qin，業務層上無需關心分布式事務機制的約束，Seata 正是往這個方向發展的，因此它非常值得期待，它將給我們的微服務架構帶來質的提升。

那 Seata 是怎么做到的呢？下面說說它的各個模塊之間的關系。

Seata 的設計思路是將一個分布式事務可以理解成一個全局事務，下面掛了若干個分支事務，而一個分支事務是一個滿足 ACID 的本地事務，因此我們可以操作分布式事務像操作本地事務一樣。

Seata 內部定義了 3個模塊來處理全局事務和分支事務的關系和處理過程，這三個組件分別是：

?Transaction Coordinator (TC)：事務協調器，維護全局事務的運行狀態，負責協調并驅動全局事務的提交或回滾。

?Transaction Manager (TM)：控制全局事務的邊界，負責開啟一個全局事務，并最終發起全局提交或全局回滾的決議。

?Resource Manager (RM)：控制分支事務，負責分支注冊、狀態匯報，并接收事務協調器的指令，驅動分支（本地）事務的提交和回滾。

簡要說說整個全局事務的執行步驟：

1.TM 向 TC 申請開啟一個全局事務，TC 創建全局事務后返回全局唯一的 XID，XID 會在全局事務的上下文中傳播；

2.RM 向 TC 注冊分支事務，該分支事務歸屬于擁有相同 XID 的全局事務；

3.TM 向 TC 發起全局提交或回滾；

4.TC 調度 XID 下的分支事務完成提交或者回滾。

與 XA 方案有什么不同？

Seata 的事務提交方式跟 XA 協議的兩段式提交在總體上來說基本是一致的，那它們之間有什么不同呢？

我們都知道 XA 協議它依賴的是數據庫層面來保障事務的一致性，也即是說 XA 的各個分支事務是在數據庫層面上驅動的，由于 XA 的各個分支事務需要有 XA 的驅動程序，一方面會導致數據庫與 XA 驅動耦合，另一方面它會導致各個分支的事務資源鎖定周期長，這也是它沒有在互聯網公司流行的重要因素。

基于 XA 協議以上的問題，Seata 另辟蹊徑，既然在依賴數據庫層會導致這么多問題，那我就從應用層做手腳，這還得從 Seata 的 RM 模塊說起，前面也說過 RM 的主要作用了，其實 RM 在內部做了對數據庫操作的代理層，如下：

Seata 在數據源做了一層代理層，所以我們使用 Seata 時，我們使用的數據源實際上用的是 Seata 自帶的數據源代理 DataSourceProxy，Seata 在這層代理中加入了很多邏輯，主要是解析 SQL，把業務數據在更新前后的數據鏡像組織成回滾日志，并將 undo log 日志插入 undo_log 表中，保證每條更新數據的業務 sql 都有對應的回滾日志存在。

這樣做的好處就是，本地事務執行完可以立即釋放本地事務鎖定的資源，然后向 TC 上報分支狀態。當 TM 決議全局提交時，就不需要同步協調處理了，TC 會異步調度各個 RM 分支事務刪除對應的 undo log 日志即可，這個步驟非常快速地可以完成；當 TM 決議全局回滾時，RM 收到 TC 發送的回滾請求，RM 通過 XID 找到對應的 undo log 回滾日志，然后執行回滾日志完成回滾操作。

如上圖所示，XA 方案的 RM 是放在數據庫層的，它依賴了數據庫的 XA 驅動程序。

如上圖所示，Seata 的 RM 實際上是已中間件的形式放在應用層，不用依賴數據庫對協議的支持，完全剝離了分布式事務方案對數據庫在協議支持上的要求。

分支事務如何提交和回滾？

下面詳細說說分支事務是如何提交和回滾的：

?第一階段：

分支事務利用 RM 模塊中對 JDBC 數據源代理，加入了若干流程，對業務 SQL 進行解釋，把業務數據在更新前后的數據鏡像組織成回滾日志，并生成 undo log 日志，對全局事務鎖的檢查以及分支事務的注冊等，利用本地事務 ACID 特性，將業務 SQL 和 undo log 寫入同一個事物中一同提交到數據庫中，保證業務 SQL 必定存在相應的回滾日志，最后對分支事務狀態向 TC 進行上報。

?第二階段：

TM決議全局提交：

當 TM 決議提交時，就不需要同步協調處理了，TC 會異步調度各個 RM 分支事務刪除對應的 undo log 日志即可，這個步驟非常快速地可以完成。這個機制對于性能提升非常關鍵，我們知道正常的業務運行過程中，事務執行的成功率是非常高的，因此可以直接在本地事務中提交，這步對于提升性能非常顯著。

TM決議全局回滾：

當 TM 決議回滾時，RM 收到 TC 發送的回滾請求，RM 通過 XID 找到對應的 undo log 回滾日志，然后利用本地事務 ACID 特性，執行回滾日志完成回滾操作并刪除 undo log 日志，最后向 TC 進行回滾結果上報。

業務對以上所有的流程都無感知，業務完全不關心全局事務的具體提交和回滾，而且最重要的一點是 Seata 將兩段式提交的同步協調分解到各個分支事務中了，分支事務與普通的本地事務無任何差異，這意味著我們使用 Seata 后，分布式事務就像使用本地事務一樣，完全將數據庫層的事務協調機制交給了中間件層 Seata 去做了，這樣雖然事務協調搬到應用層了，但是依然可以做到對業務的零侵入，從而剝離了分布式事務方案對數據庫在協議支持上的要求，且 Seata 在分支事務完成之后直接釋放資源，極大減少了分支事務對資源的鎖定時間，完美避免了 XA 協議需要同步協調導致資源鎖定時間過長的問題。

其它方案的補充

上面說的其實是 Seata 的默認模式，也叫 AT 模式，它是類似于 XA 方案的兩段式提交方案，并且是對業務無侵入，但是這種機制依然是需要依賴數據庫本地事務的 ACID 特性，有沒有發現，我在上面的圖中都強調了必須是支持 ACID 特性的關系型數據庫，那么問題就來了，非關系型或者不支持 ACID 的數據庫就無法使用 Seata 了，別慌，Seata 現階段為我們準備了另外一種模式，叫 MT 模式，它是一種對業務有入qin的方案，提交回滾等操作需要我們自行定義，業務邏輯需要被分解為 Prepare/Commit/Rollback 3 部分，形成一個 MT 分支，加入全局事務，它存在的意義是為 Seata 觸達更多的場景。

只不過，它不是 Seata “主打”的模式，它的存在僅僅作為補充的方案，從以上官方的發展遠景就可以看出來，Seata 的目標是始終是對業務無入qin的方案。

最后
歡迎大家一起交流，喜歡文章記得點個贊喲，感謝支持！