[[395191]]

Seata 是一款開源的分布式事務解決方案，star 高達 19200+，社區活躍度極高，致力于在微服務架構下提供高性能和簡單易用的分布式事務服務。

目錄

• XA模式是什么?
• 什么是 Seata 的事務模式?
• AT模式是什么?
• 為什么Seata要支持XA模式?
• AT與XA之間的關系
• 總結

1. XA模式是什么?

首先正如煊檍兄所言，了解了什么是XA與什么是Seata定義的事務模式，便一目了然。

1.1 什么是XA

用非常官方的話來說

XA 規范 是 X/Open 組織定義的分布式事務處理(DTP，Distributed Transaction Processing)標準。

XA 規范 描述了全局的事務管理器與局部的資源管理器之間的接口。XA規范 的目的是允許的多個資源(如數據庫，應用服務器，消息隊列等)在同一事務中訪問，這樣可以使 ACID 屬性跨越應用程序而保持有效。

XA 規范 使用兩階段提交(2PC，Two-Phase Commit)來保證所有資源同時提交或回滾任何特定的事務。

XA 規范 在上世紀 90 年代初就被提出。目前，幾乎所有主流的數據庫都對 XA 規范 提供了支持。

1.2 什么是Seata的事務模式?

Seata 定義了全局事務的框架。全局事務 定義為若干 分支事務 的整體協調：1.TM 向 TC 請求發起(Begin)、提交(Commit)、回滾(Rollback)全局事務。2.TM 把代表全局事務的 XID 綁定到分支事務上。3.RM 向 TC 注冊，把分支事務關聯到 XID 代表的全局事務中。4.RM 把分支事務的執行結果上報給 TC。(可選) 5.TC 發送分支提交(Branch Commit)或分支回滾(Branch Rollback)命令給 RM。

Seata 的 全局事務 處理過程，分為兩個階段：執行階段 ：執行 分支事務，并 保證 執行結果滿足是 可回滾的(Rollbackable) 和 持久化的(Durable)。完成階段：根據 執行階段 結果形成的決議，應用通過 TM 發出的全局提交或回滾的請求給 TC， TC 命令 RM 驅動 分支事務 進行 Commit 或 Rollback。Seata 的所謂 事務模式 是指：運行在 Seata 全局事務框架下的 分支事務 的行為模式。準確地講，應該叫作 分支事務模式。不同的 事務模式 區別在于 分支事務 使用不同的方式達到全局事務兩個階段的目標。即，回答以下兩個問題：執行階段 ：如何執行并 保證 執行結果滿足是 可回滾的(Rollbackable) 和 持久化的(Durable)。完成階段：收到 TC 的命令后，做到事務的回滾/提交

2. 那么什么是Seata XA 模式?

XA 模式：在 Seata 定義的分布式事務框架內，利用事務資源(數據庫、消息服務等)對 XA 協議的支持，以 XA 協議的機制來管理分支事務的一種 事務模式。執行階段：可回滾：業務 SQL 操作放在 XA 分支中進行，由資源對 XA 協議的支持來保證 可回滾 持久化：XA 分支完成后，執行 XA prepare，同樣，由資源對 XA 協議的支持來保證 持久化(即，之后任何意外都不會造成無法回滾的情況) 完成階段：分支提交：執行 XA 分支的 commit 分支回滾：執行 XA 分支的 rollback

以下是XA模式在Seata所定義的事務模式下的設計模型圖片

2.1 什么是Seata AT(TXC) 模式?

去年 1 月份，Seata 開源了 AT 模式。AT 模式是一種無侵入的分布式事務解決方案。在 AT 模式下，用戶只需關注自己的“業務 SQL”，用戶的 “業務 SQL” 作為一階段，Seata 框架會自動生成事務的二階段提交和回滾操作。

通過簡介，其實可以發現AT模式的特點，只需關注自己的業務sql，對業務無入侵的一種分布式事務模式。那么我們應該知道他是怎么對業務做到無入侵的?

2.2 AT 模式如何做到對業務的無侵入 ?

AT模式一階段

• 首先，在Seata的組件中，如果你想開啟分布式事務，那么就應該在你的業務入口或者事務發起入口加上@GlobalTransactional注解
• 如果你是AT模式就要做好數據源代理(seata1.0后全面支持自動代理)，并被sqlsessionfactroy使用(或者直接jdbc操作使用被代理數據源)

可以發現比較關鍵的異步，與其他模式的區別便是代理數據源，而代理數據源又有什么奧秘呢?

如上圖所示，你的數據源被代理后，通過被DataSourceProxy代理后，你所執行的sql，會被提取，解析，保存前鏡像后，再執行業務sql，再保存后鏡像，以便與后續出現異常，進行二階段的回滾操作。

2.3 AT 模式如何保證隔離性

首先我們拿到官網所展示的文檔來更直觀的描述：

可以通過上圖得出：

一階段本地事務提交前，需要確保先拿到 全局鎖 。

拿不到 全局鎖 ，不能提交本地事務。

拿 全局鎖 的嘗試被限制在一定范圍內，超出范圍將放棄，并回滾本地事務，釋放本地鎖。

兩個全局事務 tx1 和 tx2，分別對 a 表的 m 字段進行更新操作，m 的初始值 1000。

tx1 先開始，開啟本地事務，拿到本地鎖，更新操作 m = 1000 - 100 = 900。

本地事務提交前，先拿到該記錄的 全局鎖 ，本地提交釋放本地鎖。

tx2 后開始，開啟本地事務，拿到本地鎖，更新操作 m = 900 - 100 = 800。

本地事務提交前，嘗試拿該記錄的 全局鎖 ，tx1 全局提交前，

該記錄的全局鎖被 tx1 持有，tx2 需要重試等待 全局鎖 ，如tx2等待所超時，那么tx2便回滾本地事務所以他不會產生臟數據。

AT 模式二階段提交

二階段如果是提交的話，因為“業務 SQL”在一階段已經提交至數據庫， 所以 Seata 框架只需將一階段保存的快照數據和行鎖刪掉，完成數據清理即可。

AT 模式二階段回滾

二階段如果是回滾的話，Seata 就需要回滾一階段已經執行的“業務 SQL”，還原業務數據。回滾方式便是用“before image”還原業務數據;但在還原前要首先要校驗臟寫， 對比“數據庫當前業務數據”和 “after image”， 如果兩份數據完全一致就說明沒有臟寫，可以還原業務數據，如果不一致就說明有臟寫， 出現臟寫就需要轉人工處理。

完整的AT在Seata所制定的事務模式下的模型圖：

3. 為什么支持XA?

首先我們應該從AT去做判斷，為什么Seata有了AT模式還去做XA的支持

• 從視角出發：首先，我們來總結下AT模式，首先所有的事物發起，都是從TM(不僅AT) 且數據的讀已提交只能在應用中見效(用戶自行開發的系統)，對資源的查看，無法做到全方面 而XA可讓資源也感知到自身已處于全局事務中，對資源的隔離性可由數據庫本身來實現，滿足 全局一致性
• 從入侵性，數據庫支持角度：業務無入侵的更徹底，少于2個服務的操作，僅使用本地事務即可滿足一致性，而AT需要 全局鎖來保證隔離性，所以無論是1個服務，單庫的操作，還是n個服務都需要開啟全局事務來保證 隔離性。對數據庫的支持，如果AT需要支持mysql，pgsql，oracle以外的數據庫，需要做適配，并且 對復雜sql的解析成本更大，開發效率低，支持的sql數量少，XA可全方位支持數據庫的sql語句 多語言支持，如果你有java應用已經使用了seata xa那么本地數據庫已經幫我們保證了隔離 性，即便其余seata不支持的語言和java并行處理下，數據也不會出現不一致的情況。

4. 為什么Seata要支持XA模式?

• 數據鎖定：在整個事務處理過程結束前，涉及數據都被鎖定，讀寫都按隔離級別的定義約束起來。
• AT 模式使用 全局鎖 保障基本的 寫隔離，實際上也是鎖定數據的，只不過鎖在 TC 側集中管理 解鎖效率高且沒有阻塞的問題，且XA本地數據庫可能持有間隙鎖，造成鎖的粒度更大，鎖定更多無辜數據
• 死鎖(協議阻塞)：XA prepare 后，分支事務進入阻塞階段，收到 XA commit 或 XA rollback 前必須阻塞等待。如果沒有一個靠譜的協調者存在，比如abc三個庫的數據被二階段決議為提交，此時ab收到的指令，提交后，c庫在收到指令后掛了，并沒有提交xa事務，或者協調者沒有做到二階段重試，那么這個沒有提交的xa事務將會一直 持有鎖，造成死鎖的局面
• 性能差：性能的損耗主要來自兩個方面：一方面，事務協調過程，增加單個事務的 RT;另一方面，并發事務數 據的鎖沖突，降低吞吐。其實主要原因就是上面的阻塞跟數據鎖定造成，因為xa的一階段并非提交，如果一階段都是提交的場景下，由于At模式的一階段提交，at的性能是優于xa，因為它鎖在tc一側集中釋放，無需多個庫進行本地的鎖釋放

AT 與 XA 的關系

首先，我們要明確，無論是AT還是XA，他們都是有利用到數據庫自帶的事務特性，來保證數據一致性和隔離性

比如AT一階段提交和二階段回滾，都是執行了本地事務。比如XA的一階段和二階段，也都是利用了數據庫本身的事務特性

那么這樣一樣我們是否應該在數據庫層面進行挖掘，AT與XA的關系呢?

首先這個時候，我們肯定要從中找相同，與找不同。AT首當其沖，他有個必須品，也就是undolog表，undolog，相 信了解數據庫的同學肯定是知道。數據庫有六種日志分別是：重做日志(redo log)、回滾日志(undo log)、二進制日志(binlog)、錯誤日志(errorlog)、 慢查詢日志(slow query log)、一般查詢日志(general log)，中繼日志(relay log)

那么數據庫的undolog是做什么用的呢?undolog保存了事務發生之前的數據的一個版本，可以用于回滾，同時可以提供多版本并發控制下的讀(MVCC)

可以發現數據庫的undolog跟seata at模式的undolog的作用不謀而合，所以可以判斷，at模式的undolog就是把本地事務作用中的undolog，利用他的原理，做到了分布式事務中，來保證了分布式事務下的事務一致性。

那么說完了undolog，redolog呢?

Redolog的作用便是防止在發生故障的時間點，尚有臟頁未寫入磁盤，在重啟mysql服務的時候，根據redo log進行 重做，從而達到事務的持久性這一特性。

那么為什么Seata AT模式沒有看到redolog的存在?其實很簡單，這個redolog被隱藏的很深，也就是AT模式的一階段提交，讓數據庫作為我們的redolog，保證一階段的數據準確落盤。

這個時候是不是會想到LCN事務模式?他的undolog由數據庫來保證，缺少了一個redolog的存在。其實大可不必思念LCN事務，解析到這里，如果把AT改為一階段不提交，二階段提交時，前鏡像便是undolog，后鏡像便是redolog,也就是說AT其實就是一個不在數據庫層面，按照數據庫事務思想和實現原理的方式，做到了分布式中的事務一致性。

這時候講到這里，XA跟AT的關系應該一幕了然了，準確的說，其實應該說是分布式事務跟數據庫本地事務的關系，可以說XA的缺點造成了AT模式的出生，鎖在多側(多個庫)，資源阻塞，性能差。

而AT就像為了把事務的實現決定權從數據庫手中，放到了Seata中，自實現sql解析，自實現undolog(redolog)，既然我們沒有 辦法去直接優化數據庫在分布式事務下的問題，那么不如創造一個新的模式，去其糟粕，取其精華。

Seata AT 與 XA 的優劣

其實上面零零碎碎也說了不少各自的優缺點，現在我們總結一下分3點來做比較

• sql支持
• 隔離性
• 侵入性

我們先講第一點，由于上面我們總結了，其實AT就是一個自實現的XA事務，所以其實可以知道，AT在sql支持上，是遠不及利用本地事務的XA模式，既然AT需要做sql解析，那么背后的實現只能自己來解決，也就是靠Seata社區的貢獻者們來貢獻解決方案，這是一個長期性的關鍵問題，但是依然有很多用戶選擇了重寫sql，來獲取AT事務模式的支持。在sql支持上XA無疑是完勝的

第二點隔離性，Seata AT模式通過解析sql獲取涉及的主鍵id，生成行鎖，也就是AT模式的隔離就是靠全局鎖來保證，粒度細至行級，鎖信息存儲在Seata-Server一側。XA模式的隔離性就是由本地數據庫保證，鎖存儲在各個本地數據庫中。由于XA模式一旦執行了prepare后，再也無法重入這個XA事務，也無法跟其他XA事務共享鎖。因為XA協議，僅是通過XID來start一個xa事務，本身它不存在所謂的分支事務說法，它本事就是一個XA事務而已，也就是說它只管它自己。這時候可能由同學有疑問了，為什么我在branch_table里看到里XA分支事務呢?其實這個問題根據上面的什么是Seata事務模式可以了解到，Seata的事務模式就是由全局事務，分支事務，鎖信息所組成。而XA的分支事務，僅僅是作為一個參與方的存在，也就是說這個XA分支在Seata定義中為分支事務，作為分支信息記錄在案，方便宕機后也可以下發二階段決議信息。而AT由于鎖是自實現，也就相對XA來說，我只要知道用戶sql涉及到的數據，是不是數據這個全局事務下的，只要是我默認他就可以使用這個鎖，也就解決了重入問題。我們可以得出總結，XA的隔離性是全局的，AT的隔離性是更靈活且相對全局的(保證所有對數據的寫操作被Seata事務覆蓋)。第三點，入侵性，通過我們以上的信息，其實可以發現，誰更底層，誰的入侵性更小，所以由數據庫自身所支持的XA模式來說，無疑入侵最小，使用成本最低。

其實說到這里，大家可能會覺得XA模式怎么感覺比AT好這么多，雖然他不支持鎖重入，但是我可以避免這個情況發生呀。這時候，我畫個圖，大家可能會比較理解

上圖中，右側圖1是at模式運行時，圖2時xa模式運行時。可以很明顯，xa的阻塞帶來的性能下降時非常厲害的，特別是你的分支事務非常多，每個資源的釋放必須等到每個分支的數據庫去單獨釋放，后續的事務才能進入。雖然XA帶來的無侵入非常高，但是由于性能下降的程度太大，也就促使了AT的誕生，而現在AT,TCC,SAGA的模式的接受度也越來越高，這也正說明了開發者對性能的要求。AT可以看作時由Seata社區進行全方面優化，自研的XA模式，最大特點就是解決了XA模式的性能差的問題。TCC由Seata決定二階段狀態通知，其使用全權交托用戶，性能僅僅是2個本地事務+些許rpc開銷。SAGA整個事務鏈路，事務處理全權交托用戶編排，性能完全由用戶來保證，Seata作為事務的協助方，記錄全局事務的運行狀態。可以看出來，越高入侵性的模式其實背后可優化的點更多，越少入侵性的，也就是會被局限，只能依托組件開發者進行不定期的優化來保證性能。

總結

在當前的技術發展中，目前分布式事務就是屬于扮演東風的角色，大量的分布式，微服務化，帶來的性能提 升非常明顯，但是卻缺少一個有利的保障，我相信Seata就是承擔著這樣的一個角色，讓萬事俱備不欠東風。Seata項目的最核心的價值在于：

構建一個全面解決分布式事務問題的 標準化 平臺。

基于 Seata，上層應用架構可以根據實際場景的需求，靈活選擇合適的分布式事務解決方案。

圖片

注：本期分享借鑒于 Seata 三位 PMC 清銘、煊檍、屹遠

分享人：陳健斌(funkye) github id: a364176773

作者介紹：同盾科技高級開發工程師 、Seata Committer、Spring cloud alibaba contributor,、Mybatis-Plus contributor(by dynamic-datasource)