做微服務的時間長了幾乎都會撞上分布式事務這道坎。單體應用里一個 Transactional 就能搞定的原子性拆成多個服務、多個數(shù)據(jù)庫之后就變了味訂單服務扣了庫存賬戶服務扣款失敗這兩筆數(shù)據(jù)怎么收場Seata 的 AT 模式Automatic Transaction就是為這種場景設計的一套開源分布式事務方案它把兩階段提交的大部分復雜度收進中間件業(yè)務側(cè)往往只需要加一個注解。這篇文章我從原理講到踩坑實錄適合剛準備接 Seata 的同學也適合已經(jīng)在用卻在為全局鎖、回滾失敗頭疼的人。1. 項目概述與核心思路拆解1.1 分布式事務到底在解決什么問題先說清楚需求。假設你手下有一套微服務下單鏈路訂單服務負責落訂單表庫存服務負責扣 sku 庫存賬戶服務負責扣用戶余額。三個服務三套庫甚至可能是三套不同的數(shù)據(jù)存儲。如果它們是三個獨立的本地事務就會出現(xiàn)最經(jīng)典的對賬事故庫存扣了、余額扣了、訂單沒生成用戶罵街或者訂單生成了、庫存沒扣超賣倉庫罵街。單體時代我們沒有這個煩惱一個關系型數(shù)據(jù)庫里的事務天然具備 ACID。但服務一拆本地事務的作用域就只在自己的庫內(nèi)跨庫、跨服務的一致性問題就冒出來了。這個問題的本質(zhì)是我們需要一個“全局事務”它能把多個參與者服務/數(shù)據(jù)庫的狀態(tài)變更串成一個整體要么全部成功要么全部不生效。分布式領域有一條 BASE 理論基本可用、軟狀態(tài)、最終一致。它是對強一致性的妥協(xié)。Seata 的定位正好落在“Base兩階段提交”的加強版上它不是純理論框架而是一個可落地的中間件把全局事務的協(xié)調(diào)工作收歸到一個獨立的 TC事務協(xié)調(diào)器來統(tǒng)一管理。我習慣把問題分層來看一致性要求有多強訂單這種鏈路頻繁出現(xiàn)但失敗率低適用“最終收斂為一”的模式業(yè)務侵入有多深能不能只加注解不改業(yè)務邏輯性能開銷能忍多少每次業(yè)務操作多出來的 SQL 和網(wǎng)絡調(diào)用是多少。這三條是后面選型和對齊問題的錨點也是一旦出問題時要回到原點重新思考的地方。1.2 AT 模式的整體設計思路Seata 里有三個核心角色理解了它們后面所有配置都不會暈TCTransaction Coordinator獨立部署的服務端記錄全局事務狀態(tài)、協(xié)調(diào)各分支的提交回滾。它的作用像一個全局的“交管中心”。TMTransaction Manager嵌入在應用里的組件負責開啟全局事務、提交或回滾整體事務。通常一個注解就能驅(qū)動它。RMResource Manager也是嵌入在應用里的組件管理每個數(shù)據(jù)源的分支事務執(zhí)行分支注冊并上報執(zhí)行結果。TM 開啟全局事務后會拿到一個全局唯一標識 XID。XID 會被塞進 RPC 調(diào)用的上下文里跟著 Feign 或者其他調(diào)用鏈一路傳播到下游服務。下游服務只要在同一個 XID 下執(zhí)行事務操作就會被識別成同一個全局事務的分支。這個“XID 鏈路透傳”是 AT 模式能不能跨服務生效的關鍵我下面的常見問題里還要專門講。AT 模式里的“自動”兩個字是核心賣點。它借鑒了兩階段提交協(xié)議但對業(yè)務基本無感。秘密武器是三樣東西數(shù)據(jù)源代理DataSource Proxy、鏡像快照before/after image、undo_log 表。數(shù)據(jù)源代理會在真實執(zhí)行 SQL 之前做一次旁路解析自動記錄這行數(shù)據(jù)的“執(zhí)行前快照”然后放行業(yè)務 SQL執(zhí)行完再抓一張“執(zhí)行后快照”。這兩張快照連同分支信息寫進一個專門的 undo_log 表整個過程跟業(yè)務 SQL 處于同一個本地事務里。為什么敢稱“自動”因為回滾所需的補償 SQL 不需要你寫中間件根據(jù) before image 反推生成。這就是它比 TCC 省事的地方TCC 要求每個業(yè)務手寫 Try/Confirm/Cancel 三段邏輯AT 模式直接替你干了。從設計目標看AT 模式是“用空間換時間、用協(xié)議換侵入”多寫一張 undo 表、多幾次鏡像查詢換來業(yè)務代碼幾乎零改造換取比 XA 強一致協(xié)議好得多的可用性。2. AT 模式核心機制原理解析2.1 一階段本地事務 鏡像快照現(xiàn)在我們把一個全局事務的執(zhí)行過程放大來看。假設 A 服務是全局事務的發(fā)起方B 服務被遠程調(diào)用后作為分支參與者下面這串動作在每個參與者本地都會發(fā)生。第一步TM 獲取 XID 并開啟全局事務。第二步業(yè)務 SQL 走到 Seata 代理的數(shù)據(jù)源上。注意這里要求所有寫操作都必須經(jīng)過代理連接這是很多人埋坑的地方后面會說。進入代理之后整個過程大致是解析業(yè)務 SQL根據(jù)主鍵或更新條件定位目標行在執(zhí)行前執(zhí)行一次查詢拿到 before image修改前那一瞬間的行數(shù)據(jù)放行真實的 INSERT/UPDATE/DELETE再次查詢拿到 after image修改完成后的行數(shù)據(jù)把 before image、after image 連同 XID、branchId 編碼后寫入 undo_log 表向 TC 注冊分支事務申請全局鎖拿到全局鎖之后提交本地數(shù)據(jù)庫事務。為什么要在一個本地事務里同時完成“業(yè)務改動”和“undo_log 寫入”道理很簡單如果業(yè)務改了、日志沒寫系統(tǒng)恰好在這時崩潰回滾就沒依據(jù)了如果日志寫了、業(yè)務沒改后續(xù)校驗又會不對。只有把兩者放進同一個事務才能保證要么同時成功、要么同時失敗。還有一個值得品的設計注冊分支和申請全局鎖發(fā)生在本地事務提交之前。這意味著某個全局事務 T1 雖然本地數(shù)據(jù)已經(jīng)改完、但還沒拿到 TC 的最終裁定這期間其他全局事務不能在同一個數(shù)據(jù)行上繼續(xù)“搶跑”。全局鎖就是在這里起作用的。2.2 二階段異步提交與鏡像回滾全局事務進入二階段后TC 會根據(jù)所有分支的上報結果來定奪全部成功就發(fā)“提交”有任何一個分支失敗就發(fā)“回滾”。先看提交路徑。二階段提交時RM 接到 TC 的通知要做的事情非常輕量刪除對應分支的 undo_log。這不是非刪不可的強同步操作在實際實現(xiàn)里可以異步批量刪除。為什么提交不用回滾業(yè)務數(shù)據(jù)因為業(yè)務數(shù)據(jù)在本地事務提交那一刻已經(jīng)真實落庫了所謂全局提交本質(zhì)上只是“確認不需要反悔了”把退路undo_log清掉即可。再看回滾路徑。這是 AT 模式最見功力的一環(huán)。RM 拿到 XID 和 branchId 之后找到對應的 undo_log先把 after image 拿出來跟數(shù)據(jù)庫當前行對比。這一步叫“臟寫檢查”。如果當前數(shù)據(jù)和 after image 一致說明這段數(shù)據(jù)從分支執(zhí)行完畢到現(xiàn)在沒人動過可以放心回滾。中間件就根據(jù) before image 生成一條反向 SQL原來是 UPDATE就回滾成 BEFORE 行的全部字段值原來是 DELETE就按 before image 重新 INSERT原來是 INSERT就按 before image 的主鍵 DELETE?；貪L完成后刪除 undo_log分支回滾結束。臟寫檢查絕不是走過場。假如有一條數(shù)據(jù)被分支事務改過快照是“余額從 100 變 50”但回滾時發(fā)現(xiàn)當前余額已經(jīng)變成 20說明這期間有一個脫離全局事務控制的操作動了它。這時候中間件不會盲覆蓋因為一旦按 before image 覆蓋成 100就把別人的 20 這個合法結果也抹掉了。它會標記失敗、打印異常日志把問題留給人處理。這個設計是安全底線也是大家在日志里偶爾看到“無法回滾”的真正原因。2.3 全局鎖與并發(fā)沖突控制Seata AT 模式里其實有兩把鎖。一把是大家熟知的數(shù)據(jù)庫本地行鎖持鎖期間就是一階段那段本地事務的執(zhí)行期事務提交即釋放。另一把是全局鎖記錄在 TC 側(cè)鎖的粒度精確到某個數(shù)據(jù)資源實際實現(xiàn)里通常按主鍵或唯一鍵。全局鎖的存在意義是為了解決一個微妙的時間窗口服務 A 的業(yè)務數(shù)據(jù)已經(jīng)在本庫提交但從全局視角看整個分布式事務還沒有被裁定。此時如果服務 B 的另一個全局事務也想改同一行它必須先拿到全局鎖。全局鎖被 T1 占著T2 就得等。等不到就拋“獲取全局鎖超時”的異常T2 的本地事務回滾業(yè)務看到的就是明確失敗而不是靜默覆蓋。這個機制會在熱點行的場景下放大成一個明顯的性能問題。比如秒殺場景里大量請求對同一個庫存行做扣減每個全局事務都要排隊等全局鎖吞吐量會掉得很難看。所以選型之前一定要清楚自己的寫沖突密度否則上線后才發(fā)現(xiàn)被鎖排隊拖垮。調(diào)優(yōu)層面主要有兩個方向調(diào)大 RM 側(cè)獲取鎖的重試次數(shù)和重試間隔不同版本參數(shù)名略有差異比如 client.rm.lock.retry-times 和 client.rm.lock.retry-interval以及在業(yè)務側(cè)縮短事務的持續(xù)時間——鎖只在該全局事務存續(xù)期間持有事務窗口越短競爭越小。3. 實操從零接入 Seata AT 模式3.1 環(huán)境準備與基礎配置做一次最簡單的本地聯(lián)調(diào)我建議按下面順序來。第一步下載并啟動 TC 服務端。我用的是 seata-server 的 file 模式日志和會話都落本地文件適合學習。命令大致是這樣sh seata-server.sh -p 8091 -m file -n 1生產(chǎn)環(huán)境不要用 file 模式TC 的狀態(tài)需要放到共享存儲里并做集群部署否則 TC 一掛全局事務狀態(tài)全丟。這點切記。第二步在每個參與全局事務的業(yè)務庫中建一張 undo_log 表。官方標準 DDL 類似下面這樣我一般會在建表語句后面額外加注釋標明這個表的用途方便后來的人一眼看懂CREATE TABLE undo_log ( id BIGINT(20) NOT NULL AUTO_INCREMENT, branch_id BIGINT(20) NOT NULL, xid VARCHAR(100) NOT NULL, context VARCHAR(128) NOT NULL, rollback_info LONGBLOB NOT NULL, log_status INT(11) NOT NULL, log_created DATETIME NOT NULL, log_modified DATETIME NOT NULL, PRIMARY KEY (id), UNIQUE KEY ux_undo_log (xid, branch_id) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8;注意幾個點表名必須是 undo_log除非你改過自定義前綴的配置字段名和類型都要和中間件期望保持一致引擎一定要是 InnoDB原因你應該懂——回滾操作本身就是事務操作MyISAM 在這里連基本條件都不滿足。第三步在服務里引入 starter 依賴。以 1.8.0 版本為例dependency groupIdio.seata/groupId artifactIdseata-spring-boot-starter/artifactId version1.8.0/version /dependency第四步在 application.yml 里配上最簡的 file 模式配置spring: application: name: order-service seata: enabled: true application-id: order-service tx-service-group: default_tx_group registry: type: file config: type: file service: vgroup-mapping: default_tx_group: default grouplist: default: 127.0.0.1:8091 client: rm: lock: retry-times: 30 retry-interval: 1000這段配置里最容易出錯的是 tx-service-group 與 vgroup-mapping 的對應關系?？蛻舳擞檬聞杖航M名去找 TC 集群群組映射必須跟 TC 側(cè)配置對上否則你會看到服務啟動正常但一發(fā)起全局事務就報 no available service 或者注冊不到 TC。3.2 核心代碼寫法與數(shù)據(jù)源代理接入之后業(yè)務側(cè)的改動小到讓人懷疑是不是漏了什么。給最外層的方法加一個 GlobalTransactional 就行Service public class OrderService { GlobalTransactional(name create-order-tx, rollbackFor Exception.class, timeoutMills 10000) public Long createOrder(OrderCreateRequest req) { Order order buildOrder(req); orderMapper.insert(order); // 本地分支操作 inventoryClient.deduct(req.getSkuId(), req.getCount()); // 遠程扣庫存 accountClient.deduct(req.getUserId(), order.getAmount()); // 遠程扣余額 return order.getId(); } }GlobalTransactional 的三個屬性值得花 30 秒理解name 只是全局事務的名字方便排查日志rollbackFor 決定了哪些異常觸發(fā)回滾默認只對 RuntimeException 和 Error 生效遇到 checked exception 時想回滾必須顯式指定 Exception.class這是我見過最多的“注解失效”原因timeoutMills 是全局事務的超時時間超過它 TC 會強制把事務標記為超時回滾所以這個值要留足余量不能比最長的業(yè)務鏈路還短。數(shù)據(jù)源代理這塊starter 默認會開啟自動代理seata.enable-auto-data-source-proxy 默認 true它會把業(yè)務方的 DataSource 包裝成 DataSourceProxy。但有幾種情況代理不生效后續(xù)常見問題里我詳細說。核心原則只有一條你的所有寫 SQL 都要走被 Seata 代理過的連接別圖省事自己在代碼里 new 一個裸連接。還有一個容易被忽略的細節(jié)是 XID 透傳。如果你們用的是 Feign而 starter 里自帶的攔截器沒生效就需要自己補一個Component public class FeignXidInterceptor implements RequestInterceptor { Override public void apply(RequestTemplate template) { String xid RootContext.getXID(); if (xid ! null) { template.header(RootContext.KEY_XID, xid); } } }這個攔截器做的事情很單純把當前線程里的 XID 塞進 HTTP 頭下游服務再從請求頭里把它取出來塞回自己的線程上下文。一旦這一步丟鏈下游就永遠意識不到自己屬于哪個全局事務。3.3 一個完整的下單鏈路演示我習慣直接用“余額不足”的場景來驗證 AT 模式是否真的在工作。步驟很簡單調(diào) createOrder讓賬戶服務在扣款時故意拋異常然后看庫存服務那邊的庫存是否回滾。鏈路是這樣的。TM 在訂單服務里開啟全局事務XID 生成。訂單服務先落訂單本地事務提交。隨后調(diào)用庫存服務庫存服務通過透傳過來的 XID 加入同一全局事務扣減庫存并寫好 undo_log注冊分支提交本地事務。最后調(diào)用賬戶服務賬戶服務同樣加入全局事務但在余額校驗時拋了業(yè)務異常。賬戶服務的本地事務回滾分支上報失敗。TC 裁決全局回滾通知庫存服務回滾。庫存服務的 RM 拿到 undo_log對比 after image 和當前行確認數(shù)據(jù)沒被額外改動于是依據(jù) before image 把扣掉的庫存加回來再把 undo_log 刪除。整個下單接口最終表現(xiàn)為“訂單不存在、庫存沒變、余額沒少”三庫數(shù)據(jù)歸位。我在本地復現(xiàn)時會在日志里盯著三行關鍵輸出全局事務開啟的 XID庫存服務注冊分支的 branchId回滾完成后 undo_log 被刪除的記錄。三者都能對上說明 AT 模式的閉環(huán)真的走通了。A 同學踩過一個很經(jīng)典的坑他只給訂單服務開了異步線程池里的 Feign 調(diào)用XID 在異步線程里丟了下游庫存服務根本沒進全局事務全局回滾時自然沒有庫存分支數(shù)據(jù)就亂了。后面我用代碼顯式傳遞了 XID 上下文才解決。4. 常見問題與排查經(jīng)驗4.1 回滾失效與臟寫檢查先看一個高頻現(xiàn)象接口確實拋了異常全局事務日志里也顯示回滾了但數(shù)據(jù)庫里數(shù)據(jù)沒還原。這種“假回滾”的根源90% 是分支根本沒進全局事務另外 10% 是回滾路線上被臟寫卡住。分支沒進全局事務常見原因有三個。第一XID 沒有透傳到下游Feign 或 RPC 的攔截器缺失下游不認識這個全局事務它只是在普通本地事務里各自為政。第二數(shù)據(jù)源沒有被代理你自己手動創(chuàng)建了 DataSource 或者在特定代碼路徑直接拿了原始連接中間件就沒機會生成 undo_log。第三tx-service-group 映射錯誤分支服務映射到的 TC 集群跟發(fā)起方不一致看起來都連上了實際上不是同一個全局事務。臟寫檢查失敗又是另一種情況。日志里如果出現(xiàn) “Status of data changed in global transaction” 這類表述意思是回滾時拿到的當前行數(shù)據(jù)跟 after image 對不上。我在真實項目中碰到過一次一個定時任務用裸 JDBC 直接改了訂單表的備注字段恰好訂單行處于某個全局事務的窗口期內(nèi)回滾校驗就失敗了。這種問題沒法靠中間件自動解決只能限定所有寫路徑都走代理或者把這種離線任務統(tǒng)一收口。4.2 全局鎖等待超時另一個高頻且更折磨人的問題全局鎖獲取超時。日志往往長這樣Could not get global lock, xid xxx, branchId yyy原因幾乎都是同一個某個熱點行被另一個未結算完的全局事務占著。常見于秒殺、搶購、庫存扣減、余額扣減這類場景。我的排查套路是三步。第一步看 TC 消息或日志確認持鎖的 XID 是誰、持了多久。第二步看這個 XID 的全局事務為什么遲遲不結束——是不是業(yè)務里混了大查詢、慢 SQL 甚至手工 sleep把事務窗口拉長了。第三步才會去考慮調(diào)參數(shù)。調(diào)參也只是緩解不是根治把鎖重試次數(shù)和間隔調(diào)大能容忍更長的排隊但吞吐上不去。真正的解決方案在前面提過縮短事務時間拆小事務粒度或者對熱點資源做前置串行化。如果業(yè)務上允許把熱點更新從全局事務里摘出去改用消息驅(qū)動的最終一致是比死磕鎖參數(shù)更健康的選擇。4.3 其他高頻坑速查表我把這幾個月的實戰(zhàn)問題整理成了一張速查表基本可以貼在 IDE 旁邊現(xiàn)象常見原因處理建議發(fā)起全局事務時報 no available service客戶端 tx-service-group 與 vgroup-mapping 對不上核對所有參與方的群組映射和 TC 地址回滾流程沒有覆蓋下游服務XID 沒有通過 Feign/異步鏈路透傳啟用或補一個 Feign/HTTP 攔截器傳遞 XID日志顯示回滾成功但數(shù)據(jù)沒還原分支 SQL 沒有走代理數(shù)據(jù)源檢查自建數(shù)據(jù)源、原生連接等旁路路徑回滾時臟寫檢查失敗窗口期內(nèi)有非代理操作改了同一行所有寫路徑統(tǒng)一走代理必要時業(yè)務補償GlobalTransactional 對 checked exception 不回滾默認只回滾 RuntimeException/Error顯式設置 rollbackFor Exception.classundo_log 表持續(xù)膨脹二階段異步刪除不及時或事務頻繁回滾定期清理評估能否開異步 commit 優(yōu)化熱點行場景吞吐驟降全局鎖排隊嚴重縮短事務窗口或考慮改用 TCC/消息方案這張表里每一行都是我或者身邊同事真金白銀踩出來的。建議先收藏上線前對著過一遍能省掉好幾個凌晨的告警電話。5. 使用邊界與實戰(zhàn)心得5.1 到底什么場景適合 AT 模式選型的時候我的判斷順序是這樣的先問業(yè)務能不能接受最終一致如果能優(yōu)先考慮消息異步如果必須強一致再看能不能接受 AT 模式的鎖競爭和額外開銷。AT 模式最舒服的場景是寫沖突不高、失敗率低、但失敗后必須嚴格回滾的鏈路。典型的比如普通商城的下單、出庫、支付回調(diào)。這類業(yè)務日常并發(fā)不夸張熱點行競爭不明顯代碼改造量又小AT 模式幾乎是性價比最高的選擇。反過來這些場景要慎重極高并發(fā)下對同一個行反復讀寫熱點競賽單個全局事務里揉進大量慢 SQL、外部 HTTP、文件操作導致事務窗口動輒幾十秒數(shù)據(jù)庫不是 InnoDB 或不具備造 undo_log 表條件的環(huán)境。另外如果你只追求跨服務調(diào)用最終一致、且對數(shù)據(jù)丟失不敏感直接上消息隊列做可靠異步投遞比引入分布式事務中間件都輕。5.2 常見分布式事務方案對比做個直給的對比方便你心里有個坐標系方案一致性侵入性性能適用場景XA 兩階段強一致中低鎖持有時間長低并發(fā)強一致場景Seata AT讀已提交加強低注解代理中多一次鏡像和全局鎖絕大多數(shù)微服務寫鏈路TCC最終一致高手寫三方法中高強約束的資源預留如庫存預占Saga最終一致高手動補償高長流程業(yè)務編排我個人的感受是AT 和 TCC 不是替代關系而是梯度關系。項目初期鏈路簡單先上 AT 把一致性兜住等業(yè)務增長到熱點沖突成為瓶頸再針對那一條熱點鏈路替換成 TCC 或者異步消息其他鏈路繼續(xù)保持 AT。死磕單一方案往往得不償失。5.3 個人經(jīng)驗與調(diào)優(yōu)建議最后分享幾條壓測和運維層面的建議。第一先量一下“同一條熱點行的并發(fā)寫”能扛到多少。我見過一個項目前期聯(lián)調(diào)都正常壓測到一定并發(fā)后全局鎖排隊超時像是約好了一樣集體爆發(fā)。提前壓測心里有數(shù)。第二事務窗口能縮多短就縮多短。把無關的遠程調(diào)用、大查詢挪到事務外面只為真正需要一致性的幾步開全局事務。第三別忽略 TC 的高可用。TC 掛了全局事務就沒法收工生產(chǎn)必須用共享存儲加多節(jié)點部署再配合配置中心和注冊中心做動態(tài)發(fā)現(xiàn)。第四日志和監(jiān)控要讓 XID 貫穿始終不然出問題你連從哪個分支開始查都找不到。如果只是查詢場景需要保持一致性別輕易套全局事務用 GlobalLock 或者 select for update 往往更輕快。這個細節(jié)容易被忽略但壓測時差距很明顯。我在實際操作中的體會是Seata AT 模式是“成本最低的分布式事務入門方案”但它不是銀彈。你越早把它當成一個有鎖競爭、有額外開銷的工程組件來看待越少在線上被它打臉。好好設計事務邊界配合合理的壓測和監(jiān)控它會比你想的可靠得多。