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