Seata 是一款開源的分布式事務(wù)解決方案，star 高達(dá) 19200+，社區(qū)活躍度極高，致力于在微服務(wù)架構(gòu)下提供高性能和簡單易用的分布式事務(wù)服務(wù)。
目錄
1. XA模式是什么?
首先正如煊檍兄所言，了解了什么是XA與什么是Seata定義的事務(wù)模式，便一目了然。
1.1 什么是XA
用非常官方的話來說
XA 規(guī)范 是 X/Open 組織定義的分布式事務(wù)處理(DTP，Distributed Transaction Processing)標(biāo)準(zhǔn)。
XA 規(guī)范 描述了全局的事務(wù)管理器與局部的資源管理器之間的接口。XA規(guī)范 的目的是允許的多個(gè)資源(如數(shù)據(jù)庫，應(yīng)用服務(wù)器，消息隊(duì)列等)在同一事務(wù)中訪問，這樣可以使 ACID 屬性跨越應(yīng)用程序而保持有效。
XA 規(guī)范 使用兩階段提交(2PC，Two-Phase Commit)來保證所有資源同時(shí)提交或回滾任何特定的事務(wù)。
XA 規(guī)范 在上世紀(jì) 90 年代初就被提出。目前，幾乎所有主流的數(shù)據(jù)庫都對 XA 規(guī)范 提供了支持。
1.2 什么是Seata的事務(wù)模式?
Seata 定義了全局事務(wù)的框架。全局事務(wù) 定義為若干 分支事務(wù) 的整體協(xié)調(diào)：1.TM 向 TC 請求發(fā)起(Begin)、提交(Commit)、回滾(Rollback)全局事務(wù)。2.TM 把代表全局事務(wù)的 XID 綁定到分支事務(wù)上。3.RM 向 TC 注冊，把分支事務(wù)關(guān)聯(lián)到 XID 代表的全局事務(wù)中。4.RM 把分支事務(wù)的執(zhí)行結(jié)果上報(bào)給 TC。(可選) 5.TC 發(fā)送分支提交(Branch Commit)或分支回滾(Branch Rollback)命令給 RM。
Seata 的 全局事務(wù) 處理過程，分為兩個(gè)階段：執(zhí)行階段 ：執(zhí)行 分支事務(wù)，并 保證 執(zhí)行結(jié)果滿足是 可回滾的(Rollbackable) 和 持久化的(Durable)。完成階段：根據(jù) 執(zhí)行階段 結(jié)果形成的決議，應(yīng)用通過 TM 發(fā)出的全局提交或回滾的請求給 TC， TC 命令 RM 驅(qū)動(dòng) 分支事務(wù) 進(jìn)行 Commit 或 Rollback。Seata 的所謂 事務(wù)模式 是指：運(yùn)行在 Seata 全局事務(wù)框架下的 分支事務(wù) 的行為模式。準(zhǔn)確地講，應(yīng)該叫作 分支事務(wù)模式。不同的 事務(wù)模式 區(qū)別在于 分支事務(wù) 使用不同的方式達(dá)到全局事務(wù)兩個(gè)階段的目標(biāo)。即，回答以下兩個(gè)問題：執(zhí)行階段 ：如何執(zhí)行并 保證 執(zhí)行結(jié)果滿足是 可回滾的(Rollbackable) 和 持久化的(Durable)。完成階段：收到 TC 的命令后，做到事務(wù)的回滾/提交
2. 那么什么是Seata XA 模式?
XA 模式：在 Seata 定義的分布式事務(wù)框架內(nèi)，利用事務(wù)資源(數(shù)據(jù)庫、消息服務(wù)等)對 XA 協(xié)議的支持，以 XA 協(xié)議的機(jī)制來管理分支事務(wù)的一種 事務(wù)模式。執(zhí)行階段：可回滾：業(yè)務(wù) SQL 操作放在 XA 分支中進(jìn)行，由資源對 XA 協(xié)議的支持來保證 可回滾 持久化：XA 分支完成后，執(zhí)行 XA prepare，同樣，由資源對 XA 協(xié)議的支持來保證 持久化(即，之后任何意外都不會(huì)造成無法回滾的情況) 完成階段：分支提交：執(zhí)行 XA 分支的 commit 分支回滾：執(zhí)行 XA 分支的 rollback
以下是XA模式在Seata所定義的事務(wù)模式下的設(shè)計(jì)模型圖片
2.1 什么是Seata AT(TXC) 模式?
去年 1 月份，Seata 開源了 AT 模式。AT 模式是一種無侵入的分布式事務(wù)解決方案。在 AT 模式下，用戶只需關(guān)注自己的“業(yè)務(wù) SQL”，用戶的 “業(yè)務(wù) SQL” 作為一階段，Seata 框架會(huì)自動(dòng)生成事務(wù)的二階段提交和回滾操作。
通過簡介，其實(shí)可以發(fā)現(xiàn)AT模式的特點(diǎn)，只需關(guān)注自己的業(yè)務(wù)sql，對業(yè)務(wù)無入侵的一種分布式事務(wù)模式。那么我們應(yīng)該知道他是怎么對業(yè)務(wù)做到無入侵的?
2.2 AT 模式如何做到對業(yè)務(wù)的無侵入 ?
AT模式一階段
- 首先，在Seata的組件中，如果你想開啟分布式事務(wù)，那么就應(yīng)該在你的業(yè)務(wù)入口或者事務(wù)發(fā)起入口加上@GlobalTransactional注解
- 如果你是AT模式就要做好數(shù)據(jù)源代理(seata1.0后全面支持自動(dòng)代理)，并被sqlsessionfactroy使用(或者直接jdbc操作使用被代理數(shù)據(jù)源)
可以發(fā)現(xiàn)比較關(guān)鍵的異步，與其他模式的區(qū)別便是代理數(shù)據(jù)源，而代理數(shù)據(jù)源又有什么奧秘呢?
如上圖所示，你的數(shù)據(jù)源被代理后，通過被DataSourceProxy代理后，你所執(zhí)行的sql，會(huì)被提取，解析，保存前鏡像后，再執(zhí)行業(yè)務(wù)sql，再保存后鏡像，以便與后續(xù)出現(xiàn)異常，進(jìn)行二階段的回滾操作。
2.3 AT 模式如何保證隔離性
首先我們拿到官網(wǎng)所展示的文檔來更直觀的描述：
可以通過上圖得出：
一階段本地事務(wù)提交前，需要確保先拿到 全局鎖 。
拿不到 全局鎖 ，不能提交本地事務(wù)。
拿 全局鎖 的嘗試被限制在一定范圍內(nèi)，超出范圍將放棄，并回滾本地事務(wù)，釋放本地鎖。
兩個(gè)全局事務(wù) tx1 和 tx2，分別對 a 表的 m 字段進(jìn)行更新操作，m 的初始值 1000。
tx1 先開始，開啟本地事務(wù)，拿到本地鎖，更新操作 m = 1000 - 100 = 900。
本地事務(wù)提交前，先拿到該記錄的 全局鎖 ，本地提交釋放本地鎖。
tx2 后開始，開啟本地事務(wù)，拿到本地鎖，更新操作 m = 900 - 100 = 800。
本地事務(wù)提交前，嘗試拿該記錄的 全局鎖 ，tx1 全局提交前，
該記錄的全局鎖被 tx1 持有，tx2 需要重試等待 全局鎖 ，如tx2等待所超時(shí)，那么tx2便回滾本地事務(wù)所以他不會(huì)產(chǎn)生臟數(shù)據(jù)。
AT 模式二階段提交
二階段如果是提交的話，因?yàn)?ldquo;業(yè)務(wù) SQL”在一階段已經(jīng)提交至數(shù)據(jù)庫， 所以 Seata 框架只需將一階段保存的快照數(shù)據(jù)和行鎖刪掉，完成數(shù)據(jù)清理即可。
AT 模式二階段回滾
二階段如果是回滾的話，Seata 就需要回滾一階段已經(jīng)執(zhí)行的“業(yè)務(wù) SQL”，還原業(yè)務(wù)數(shù)據(jù)。回滾方式便是用“before image”還原業(yè)務(wù)數(shù)據(jù);但在還原前要首先要校驗(yàn)臟寫， 對比“數(shù)據(jù)庫當(dāng)前業(yè)務(wù)數(shù)據(jù)”和 “after image”， 如果兩份數(shù)據(jù)完全一致就說明沒有臟寫，可以還原業(yè)務(wù)數(shù)據(jù)，如果不一致就說明有臟寫， 出現(xiàn)臟寫就需要轉(zhuǎn)人工處理。
完整的AT在Seata所制定的事務(wù)模式下的模型圖：
3. 為什么支持XA?
首先我們應(yīng)該從AT去做判斷，為什么Seata有了AT模式還去做XA的支持
- 從視角出發(fā)：首先，我們來總結(jié)下AT模式，首先所有的事物發(fā)起，都是從TM(不僅AT) 且數(shù)據(jù)的讀已提交只能在應(yīng)用中見效(用戶自行開發(fā)的系統(tǒng))，對資源的查看，無法做到全方面 而XA可讓資源也感知到自身已處于全局事務(wù)中，對資源的隔離性可由數(shù)據(jù)庫本身來實(shí)現(xiàn)，滿足 全局一致性
- 從入侵性，數(shù)據(jù)庫支持角度：業(yè)務(wù)無入侵的更徹底，少于2個(gè)服務(wù)的操作，僅使用本地事務(wù)即可滿足一致性，而AT需要 全局鎖來保證隔離性，所以無論是1個(gè)服務(wù)，單庫的操作，還是n個(gè)服務(wù)都需要開啟全局事務(wù)來保證 隔離性。對數(shù)據(jù)庫的支持，如果AT需要支持mysql，pgsql，oracle以外的數(shù)據(jù)庫，需要做適配，并且 對復(fù)雜sql的解析成本更大，開發(fā)效率低，支持的sql數(shù)量少，XA可全方位支持?jǐn)?shù)據(jù)庫的sql語句 多語言支持，如果你有java應(yīng)用已經(jīng)使用了seata xa那么本地?cái)?shù)據(jù)庫已經(jīng)幫我們保證了隔離 性，即便其余seata不支持的語言和java并行處理下，數(shù)據(jù)也不會(huì)出現(xiàn)不一致的情況。
4. 為什么Seata要支持XA模式?
- 數(shù)據(jù)鎖定：在整個(gè)事務(wù)處理過程結(jié)束前，涉及數(shù)據(jù)都被鎖定，讀寫都按隔離級別的定義約束起來。
- AT 模式使用 全局鎖 保障基本的 寫隔離，實(shí)際上也是鎖定數(shù)據(jù)的，只不過鎖在 TC 側(cè)集中管理 解鎖效率高且沒有阻塞的問題，且XA本地?cái)?shù)據(jù)庫可能持有間隙鎖，造成鎖的粒度更大，鎖定更多無辜數(shù)據(jù)
- 死鎖(協(xié)議阻塞)：XA prepare 后，分支事務(wù)進(jìn)入阻塞階段，收到 XA commit 或 XA rollback 前必須阻塞等待。如果沒有一個(gè)靠譜的協(xié)調(diào)者存在，比如abc三個(gè)庫的數(shù)據(jù)被二階段決議為提交，此時(shí)ab收到的指令，提交后，c庫在收到指令后掛了，并沒有提交xa事務(wù)，或者協(xié)調(diào)者沒有做到二階段重試，那么這個(gè)沒有提交的xa事務(wù)將會(huì)一直 持有鎖，造成死鎖的局面
- 性能差：性能的損耗主要來自兩個(gè)方面：一方面，事務(wù)協(xié)調(diào)過程，增加單個(gè)事務(wù)的 RT;另一方面，并發(fā)事務(wù)數(shù) 據(jù)的鎖沖突，降低吞吐。其實(shí)主要原因就是上面的阻塞跟數(shù)據(jù)鎖定造成，因?yàn)閤a的一階段并非提交，如果一階段都是提交的場景下，由于At模式的一階段提交，at的性能是優(yōu)于xa，因?yàn)樗i在tc一側(cè)集中釋放，無需多個(gè)庫進(jìn)行本地的鎖釋放
AT 與 XA 的關(guān)系
首先，我們要明確，無論是AT還是XA，他們都是有利用到數(shù)據(jù)庫自帶的事務(wù)特性，來保證數(shù)據(jù)一致性和隔離性
比如AT一階段提交和二階段回滾，都是執(zhí)行了本地事務(wù)。比如XA的一階段和二階段，也都是利用了數(shù)據(jù)庫本身的事務(wù)特性
那么這樣一樣我們是否應(yīng)該在數(shù)據(jù)庫層面進(jìn)行挖掘，AT與XA的關(guān)系呢?
首先這個(gè)時(shí)候，我們肯定要從中找相同，與找不同。AT首當(dāng)其沖，他有個(gè)必須品，也就是undolog表，undolog，相 信了解數(shù)據(jù)庫的同學(xué)肯定是知道。數(shù)據(jù)庫有六種日志分別是：重做日志(redo log)、回滾日志(undo log)、二進(jìn)制日志(binlog)、錯(cuò)誤日志(errorlog)、 慢查詢?nèi)罩?slow query log)、一般查詢?nèi)罩?general log)，中繼日志(relay log)
那么數(shù)據(jù)庫的undolog是做什么用的呢?undolog保存了事務(wù)發(fā)生之前的數(shù)據(jù)的一個(gè)版本，可以用于回滾，同時(shí)可以提供多版本并發(fā)控制下的讀(MVCC)
可以發(fā)現(xiàn)數(shù)據(jù)庫的undolog跟seata at模式的undolog的作用不謀而合，所以可以判斷，at模式的undolog就是把本地事務(wù)作用中的undolog，利用他的原理，做到了分布式事務(wù)中，來保證了分布式事務(wù)下的事務(wù)一致性。
那么說完了undolog，redolog呢?
Redolog的作用便是防止在發(fā)生故障的時(shí)間點(diǎn)，尚有臟頁未寫入磁盤，在重啟mysql服務(wù)的時(shí)候，根據(jù)redo log進(jìn)行 重做，從而達(dá)到事務(wù)的持久性這一特性。
那么為什么Seata AT模式?jīng)]有看到redolog的存在?其實(shí)很簡單，這個(gè)redolog被隱藏的很深，也就是AT模式的一階段提交，讓數(shù)據(jù)庫作為我們的redolog，保證一階段的數(shù)據(jù)準(zhǔn)確落盤。
這個(gè)時(shí)候是不是會(huì)想到LCN事務(wù)模式?他的undolog由數(shù)據(jù)庫來保證，缺少了一個(gè)redolog的存在。其實(shí)大可不必思念LCN事務(wù)，解析到這里，如果把AT改為一階段不提交，二階段提交時(shí)，前鏡像便是undolog，后鏡像便是redolog,也就是說AT其實(shí)就是一個(gè)不在數(shù)據(jù)庫層面，按照數(shù)據(jù)庫事務(wù)思想和實(shí)現(xiàn)原理的方式，做到了分布式中的事務(wù)一致性。
這時(shí)候講到這里，XA跟AT的關(guān)系應(yīng)該一幕了然了，準(zhǔn)確的說，其實(shí)應(yīng)該說是分布式事務(wù)跟數(shù)據(jù)庫本地事務(wù)的關(guān)系，可以說XA的缺點(diǎn)造成了AT模式的出生，鎖在多側(cè)(多個(gè)庫)，資源阻塞，性能差。
而AT就像為了把事務(wù)的實(shí)現(xiàn)決定權(quán)從數(shù)據(jù)庫手中，放到了Seata中，自實(shí)現(xiàn)sql解析，自實(shí)現(xiàn)undolog(redolog)，既然我們沒有 辦法去直接優(yōu)化數(shù)據(jù)庫在分布式事務(wù)下的問題，那么不如創(chuàng)造一個(gè)新的模式，去其糟粕，取其精華。
Seata AT 與 XA 的優(yōu)劣
其實(shí)上面零零碎碎也說了不少各自的優(yōu)缺點(diǎn)，現(xiàn)在我們總結(jié)一下分3點(diǎn)來做比較
- sql支持
- 隔離性
- 侵入性
我們先講第一點(diǎn)，由于上面我們總結(jié)了，其實(shí)AT就是一個(gè)自實(shí)現(xiàn)的XA事務(wù)，所以其實(shí)可以知道，AT在sql支持上，是遠(yuǎn)不及利用本地事務(wù)的XA模式，既然AT需要做sql解析，那么背后的實(shí)現(xiàn)只能自己來解決，也就是靠Seata社區(qū)的貢獻(xiàn)者們來貢獻(xiàn)解決方案，這是一個(gè)長期性的關(guān)鍵問題，但是依然有很多用戶選擇了重寫sql，來獲取AT事務(wù)模式的支持。在sql支持上XA無疑是完勝的
第二點(diǎn)隔離性，Seata AT模式通過解析sql獲取涉及的主鍵id，生成行鎖，也就是AT模式的隔離就是靠全局鎖來保證，粒度細(xì)至行級，鎖信息存儲(chǔ)在Seata-Server一側(cè)。XA模式的隔離性就是由本地?cái)?shù)據(jù)庫保證，鎖存儲(chǔ)在各個(gè)本地?cái)?shù)據(jù)庫中。由于XA模式一旦執(zhí)行了prepare后，再也無法重入這個(gè)XA事務(wù)，也無法跟其他XA事務(wù)共享鎖。因?yàn)閄A協(xié)議，僅是通過XID來start一個(gè)xa事務(wù)，本身它不存在所謂的分支事務(wù)說法，它本事就是一個(gè)XA事務(wù)而已，也就是說它只管它自己。這時(shí)候可能由同學(xué)有疑問了，為什么我在branch_table里看到里XA分支事務(wù)呢?其實(shí)這個(gè)問題根據(jù)上面的什么是Seata事務(wù)模式可以了解到，Seata的事務(wù)模式就是由全局事務(wù)，分支事務(wù)，鎖信息所組成。而XA的分支事務(wù)，僅僅是作為一個(gè)參與方的存在，也就是說這個(gè)XA分支在Seata定義中為分支事務(wù)，作為分支信息記錄在案，方便宕機(jī)后也可以下發(fā)二階段決議信息。而AT由于鎖是自實(shí)現(xiàn)，也就相對XA來說，我只要知道用戶sql涉及到的數(shù)據(jù)，是不是數(shù)據(jù)這個(gè)全局事務(wù)下的，只要是我默認(rèn)他就可以使用這個(gè)鎖，也就解決了重入問題。我們可以得出總結(jié)，XA的隔離性是全局的，AT的隔離性是更靈活且相對全局的(保證所有對數(shù)據(jù)的寫操作被Seata事務(wù)覆蓋)。第三點(diǎn)，入侵性，通過我們以上的信息，其實(shí)可以發(fā)現(xiàn)，誰更底層，誰的入侵性更小，所以由數(shù)據(jù)庫自身所支持的XA模式來說，無疑入侵最小，使用成本最低。
其實(shí)說到這里，大家可能會(huì)覺得XA模式怎么感覺比AT好這么多，雖然他不支持鎖重入，但是我可以避免這個(gè)情況發(fā)生呀。這時(shí)候，我畫個(gè)圖，大家可能會(huì)比較理解
上圖中，右側(cè)圖1是at模式運(yùn)行時(shí)，圖2時(shí)xa模式運(yùn)行時(shí)。可以很明顯，xa的阻塞帶來的性能下降時(shí)非常厲害的，特別是你的分支事務(wù)非常多，每個(gè)資源的釋放必須等到每個(gè)分支的數(shù)據(jù)庫去單獨(dú)釋放，后續(xù)的事務(wù)才能進(jìn)入。雖然XA帶來的無侵入非常高，但是由于性能下降的程度太大，也就促使了AT的誕生，而現(xiàn)在AT,TCC,SAGA的模式的接受度也越來越高，這也正說明了開發(fā)者對性能的要求。AT可以看作時(shí)由Seata社區(qū)進(jìn)行全方面優(yōu)化，自研的XA模式，最大特點(diǎn)就是解決了XA模式的性能差的問題。TCC由Seata決定二階段狀態(tài)通知，其使用全權(quán)交托用戶，性能僅僅是2個(gè)本地事務(wù)+些許rpc開銷。SAGA整個(gè)事務(wù)鏈路，事務(wù)處理全權(quán)交托用戶編排，性能完全由用戶來保證，Seata作為事務(wù)的協(xié)助方，記錄全局事務(wù)的運(yùn)行狀態(tài)。可以看出來，越高入侵性的模式其實(shí)背后可優(yōu)化的點(diǎn)更多，越少入侵性的，也就是會(huì)被局限，只能依托組件開發(fā)者進(jìn)行不定期的優(yōu)化來保證性能。
總結(jié)
在當(dāng)前的技術(shù)發(fā)展中，目前分布式事務(wù)就是屬于扮演東風(fēng)的角色，大量的分布式，微服務(wù)化，帶來的性能提 升非常明顯，但是卻缺少一個(gè)有利的保障，我相信Seata就是承擔(dān)著這樣的一個(gè)角色，讓萬事俱備不欠東風(fēng)。Seata項(xiàng)目的最核心的價(jià)值在于：
構(gòu)建一個(gè)全面解決分布式事務(wù)問題的 標(biāo)準(zhǔn)化 平臺。
基于 Seata，上層應(yīng)用架構(gòu)可以根據(jù)實(shí)際場景的需求，靈活選擇合適的分布式事務(wù)解決方案。
圖片
注：本期分享借鑒于 Seata 三位 PMC 清銘、煊檍、屹遠(yuǎn)
分享人：陳健斌(funkye) github id: a364176773
作者介紹：同盾科技高級開發(fā)工程師 、Seata Committer、Spring cloud alibaba contributor,、Mybatis-Plus contributor(by dynamic-datasource)
原文地址：https://mp.weixin.qq.com/s/dEw02TEVQhTOFyir4o4Dcw
