微信公眾號「後端進階」，專注後端技術分享：Java、Golang、WEB框架、分散式中介軟體、服務治理等等。

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

在今年年初，阿里開源了一個分散式事務中介軟體，起初起名為 Fescar，後改名為 Seata，在它開源之初，我就知道它肯定要火，因為這是一個解決痛點的開源專案，Seata 一開始就是衝著對業務無侵入與高效能方向走，這正是我們對解決分散式事務問題迫切的需求。因為待過的幾家公司，用的都是微服務架構，但是在解決分散式事務的問題上都不太優雅，所以我也在一直關注 Seata 的發展，今天就簡要說說它的一些設計上的原理，後續我將會對它的各個模組進行深入原始碼分析，感興趣的可以持續關注我的公眾號或者部落格，不要跟丟。

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

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

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

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

Seata 各模組之間的關係

針對上面所說的分散式事務解決方案的痛點，那很顯然，我們理想的分散式事務解決方案肯定是效能要好而且要對業務無入侵，業務層上無需關心分散式事務機制的約束，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 模式，它是一種對業務有入侵的方案，提交回滾等操作需要我們自行定義，業務邏輯需要被分解為 Prepare/Commit/Rollback 3 部分，形成一個 MT 分支，加入全域性事務，它存在的意義是為 Seata 觸達更多的場景。

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

注：本文圖片設計參考Seata官方圖

相關推薦