1. 從“分布式事務(wù)”這個老難題說起如果你做過幾年后端開發(fā)尤其是在微服務(wù)架構(gòu)下折騰過數(shù)據(jù)一致性那“分布式事務(wù)”這個詞對你來說大概率不是什么美好的回憶。訂單創(chuàng)建了庫存沒扣積分增加了優(yōu)惠券沒核銷這種“一半成功一半失敗”的爛攤子處理起來比寫業(yè)務(wù)代碼本身還頭疼。我最早接觸分布式事務(wù)解決方案時試過基于消息隊列的最終一致性也折騰過兩階段提交2PC各有各的麻煩。消息隊列方案對業(yè)務(wù)侵入大補(bǔ)償邏輯復(fù)雜而傳統(tǒng)的2PC對數(shù)據(jù)庫和中間件要求高性能瓶頸明顯在云原生和微服務(wù)拆得越來越細(xì)的今天顯得有點力不從心。正是在這種背景下像Seata這樣的分布式事務(wù)框架開始流行起來。它把那些復(fù)雜的協(xié)調(diào)、回滾邏輯封裝起來給我們提供了一套相對統(tǒng)一的編程模型。Seata支持好幾種模式比如AT自動補(bǔ)償、TCCTry-Confirm-Cancel、Saga長事務(wù)等。今天我們不聊別的就聚焦在TCC模式上。為什么是TCC因為在我看來它是業(yè)務(wù)侵入性、性能和數(shù)據(jù)強(qiáng)一致性之間一個非常不錯的平衡點。它不像AT模式那樣嚴(yán)重依賴數(shù)據(jù)庫的undo log對某些不支持undo log的數(shù)據(jù)庫或中間件不友好也不像Saga模式那樣一階段就提交可能產(chǎn)生臟讀。TCC要求我們開發(fā)者自己定義三個明確的階段Try、Confirm、Cancel雖然多寫了一些代碼但換來了對事務(wù)邊界的絕對掌控和對各種異構(gòu)數(shù)據(jù)源比如Redis、ES、MQ的支持能力。網(wǎng)上關(guān)于Seata TCC的教程不少但很多要么是官網(wǎng)示例的簡單復(fù)刻要么只講通了Demo一遇到生產(chǎn)環(huán)境的復(fù)雜場景——比如嵌套調(diào)用、并發(fā)沖突、空回滾、冪等控制——就語焉不詳。這篇文章我就結(jié)合自己最近在一個電商履約系統(tǒng)中落地Seata TCC 1.4.2的真實經(jīng)歷把從環(huán)境搭建、代碼編寫、到各種坑的排查和填平過程給你完整地捋一遍。我們的目標(biāo)是讓你看完之后不僅能跑通一個TCC示例更能理解其內(nèi)在機(jī)制具備在實際項目中設(shè)計和駕馭TCC事務(wù)的能力。2. 環(huán)境與項目骨架避開第一個坑在開始寫一行業(yè)務(wù)代碼之前先把環(huán)境搭對能省掉后面80%的莫名其妙的問題。我這次用的是Seata 1.4.2版本部署方式選擇了Docker Compose這比直接下載jar包運(yùn)行要方便和干凈得多。2.1 部署Seata Server (TC)TC是Transaction Coordinator事務(wù)協(xié)調(diào)器是Seata的大腦必須最先啟動。很多人卡在第一步就是因為沒搞清楚配置。首先你需要一個docker-compose.yml文件。網(wǎng)上很多教程給的配置還是老版本的直接抄過來可能連服務(wù)都起不來。下面是我驗證過可用的1.4.2版本配置version: 3.8 services: seata-server: image: seataio/seata-server:1.4.2 container_name: seata-server ports: - 8091:8091 # 事務(wù)協(xié)調(diào)器默認(rèn)端口 - 7091:7091 # 控制臺端口1.4.2開始自帶控制臺 environment: - SEATA_IP你的服務(wù)器IP # 重要如果是云服務(wù)器填內(nèi)網(wǎng)IP本地測試填127.0.0.1 - SEATA_PORT8091 - STORE_MODEfile # 事務(wù)日志存儲模式單機(jī)測試用file最簡單。生產(chǎn)環(huán)境請用db或redis - SERVER_NODE1 # 節(jié)點編號單機(jī)就是1 volumes: - ./seata-config:/seata-server/resources networks: - seata-net networks: seata-net: driver: bridge這里有幾個關(guān)鍵點SEATA_IP這是最大的坑。這個IP是TC服務(wù)對外暴露的地址Client你的業(yè)務(wù)服務(wù)要靠這個地址來連接TC。如果你在本地用Docker跑Client是宿主機(jī)上的Spring Boot應(yīng)用那么這里應(yīng)該填宿主機(jī)的IP127.0.0.1或本機(jī)局域網(wǎng)IP而不是容器內(nèi)部的IP。如果填錯了Client會連不上TC報“no available server to connect”錯誤。存儲模式STORE_MODEfile表示將事務(wù)日志全局事務(wù)會話、分支事務(wù)記錄等存在本地文件。這對于開發(fā)測試完全沒問題重啟容器數(shù)據(jù)就沒了。生產(chǎn)環(huán)境絕對不要用file模式因為無法支持集群和高可用。生產(chǎn)環(huán)境應(yīng)該用db模式并配置好對應(yīng)的數(shù)據(jù)庫連接信息。控制臺從1.4.2開始Seata Server自帶了一個簡單的控制臺訪問http://你的IP:7091即可默認(rèn)賬號密碼是seata/seata?？梢栽谏厦娌榭慈质聞?wù)列表和狀態(tài)對于調(diào)試非常有用。啟動命令很簡單docker-compose up -d。用docker logs -f seata-server查看日志看到 “Server started...” 的字樣就說明啟動成功了。2.2 準(zhǔn)備業(yè)務(wù)項目TM/RMTC搭好了接下來是事務(wù)參與者也就是我們的業(yè)務(wù)服務(wù)。我們需要創(chuàng)建一個簡單的多模塊Spring Boot項目來模擬分布式場景。假設(shè)我們有一個“訂單服務(wù)”和一個“庫存服務(wù)”。項目依賴是關(guān)鍵。在父pom中引入Spring Cloud和Spring Cloud Alibaba的依賴管理。注意版本兼容性我用的組合是Spring Boot: 2.3.12.RELEASESpring Cloud: Hoxton.SR12Spring Cloud Alibaba: 2.2.7.RELEASE在訂單服務(wù)和庫存服務(wù)的pom中都需要引入以下核心依賴!-- Seata 客戶端 -- dependency groupIdio.seata/groupId artifactIdseata-spring-boot-starter/artifactId version1.4.2/version /dependency !-- Spring Cloud Alibaba Nacos 作為配置和注冊中心也可用Eureka等 -- dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactId /dependency dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-config/artifactId /dependency配置文件application.yml是另一個容易出錯的地方。訂單服務(wù)作為事務(wù)發(fā)起者TM的配置示例spring: application: name: order-service cloud: nacos: discovery: server-addr: localhost:8848 # Nacos地址 config: server-addr: localhost:8848 file-extension: yaml seata: application-id: ${spring.application.name} tx-service-group: my_test_tx_group # 事務(wù)組需要和TC配置對應(yīng) enable-auto-data-source-proxy: false # TCC模式不需要數(shù)據(jù)源代理設(shè)為false config: type: nacos # 從Nacos讀取TC配置 nacos: server-addr: ${spring.cloud.nacos.config.server-addr} group: SEATA_GROUP >dependency groupIdio.seata/groupId artifactIdseata-rm-tcc/artifactId version1.4.2/version /dependency然后定義接口。這個接口必須被業(yè)務(wù)實現(xiàn)類實現(xiàn)并且方法要遵循特定規(guī)則LocalTCC // 聲明這是一個本地TCC接口 public interface InventoryTccAction { /** * Try 方法 * param businessKey 業(yè)務(wù)唯一鍵用于標(biāo)識本次操作 * param productId 商品ID * param count 扣減數(shù)量 * return 是否成功 */ TwoPhaseBusinessAction(name inventoryTccAction, commitMethod commit, rollbackMethod cancel) boolean prepare(BusinessActionContext actionContext, BusinessActionContextParameter(paramName productId) String productId, BusinessActionContextParameter(paramName count) Integer count); /** * Confirm 方法 * param actionContext 業(yè)務(wù)上下文框架自動注入包含prepare方法的參數(shù) * return 是否成功 */ boolean commit(BusinessActionContext actionContext); /** * Cancel 方法 * param actionContext 業(yè)務(wù)上下文 * return 是否成功 */ boolean cancel(BusinessActionContext actionContext); }關(guān)鍵注解解析LocalTCC: 標(biāo)識這是一個TCC接口可以是Spring Bean。TwoPhaseBusinessAction: 核心注解標(biāo)注在Try方法上。name: TCC事務(wù)的名稱全局唯一用于標(biāo)識這個業(yè)務(wù)動作。commitMethod: Confirm方法的方法名。rollbackMethod: Cancel方法的方法名。BusinessActionContextParameter: 標(biāo)注在Try方法的參數(shù)上框架會將這些參數(shù)值保存到BusinessActionContext中并自動傳遞給后續(xù)的Confirm/Cancel方法。這是TCC模式能正確回滾的關(guān)鍵因為Cancel方法需要知道Try階段凍結(jié)的是哪個商品、多少數(shù)量。3.2 實現(xiàn)TCC接口接下來是實現(xiàn)類。這里的設(shè)計直接關(guān)系到事務(wù)的可靠性。Service public class InventoryTccActionImpl implements InventoryTccAction { Autowired private InventoryMapper inventoryMapper; Override Transactional(rollbackFor Exception.class) public boolean prepare(BusinessActionContext actionContext, String productId, Integer count) { // 1. 檢查庫存是否充足 Inventory inventory inventoryMapper.selectById(productId); if (inventory null || inventory.getAvailable() count) { throw new RuntimeException(庫存不足); } // 2. 執(zhí)行預(yù)留操作凍結(jié)庫存 int frozen inventory.getFrozen() null ? 0 : inventory.getFrozen(); int newFrozen frozen count; int newAvailable inventory.getAvailable() - count; int updateCount inventoryMapper.updateFrozenAndAvailable(productId, newFrozen, newAvailable); if (updateCount ! 1) { throw new RuntimeException(凍結(jié)庫存失敗可能并發(fā)沖突); } // 3. 記錄預(yù)留日志可選但推薦用于冪等和排查 // 可以將 xid, branchId, productId, count, status(try) 插入一張單獨的日志表 log.info(TCC Try 成功。xid{}, productId{}, count{}, actionContext.getXid(), productId, count); return true; } Override Transactional(rollbackFor Exception.class) public boolean commit(BusinessActionContext actionContext) { String xid actionContext.getXid(); String productId (String) actionContext.getActionContext(productId); Integer count (Integer) actionContext.getActionContext(count); log.info(TCC Confirm 開始。xid{}, productId{}, count{}, xid, productId, count); // 1. 冪等性檢查查詢?nèi)罩颈砣绻搙id和branchId已經(jīng)執(zhí)行過confirm則直接返回true // if (tccLogService.isConfirmed(xid, branchId)) { return true; } // 2. 執(zhí)行真正的扣減將凍結(jié)的庫存清零總庫存減少 int updateCount inventoryMapper.confirmDeduct(productId, count); if (updateCount ! 1) { // 這里可能因為Try階段數(shù)據(jù)被篡改等原因失敗需要告警和人工介入 log.error(TCC Confirm 失敗xid{}, xid); // 通常Confirm不允許失敗失敗后應(yīng)不斷重試直到成功?？蚣軙卦?。 throw new RuntimeException(Confirm扣減庫存失敗); } // 3. 更新日志表狀態(tài)為 commit // tccLogService.updateStatus(xid, branchId, commit); log.info(TCC Confirm 成功。xid{}, xid); return true; } Override Transactional(rollbackFor Exception.class) public boolean cancel(BusinessActionContext actionContext) { String xid actionContext.getXid(); String productId (String) actionContext.getActionContext(productId); Integer count (Integer) actionContext.getActionContext(count); log.info(TCC Cancel 開始。xid{}, productId{}, count{}, xid, productId, count); // 1. 冪等性檢查查詢?nèi)罩颈砣绻搙id和branchId已經(jīng)執(zhí)行過cancel則直接返回true // if (tccLogService.isCancelled(xid, branchId)) { return true; } // 2. 執(zhí)行取消操作釋放凍結(jié)的庫存 int updateCount inventoryMapper.cancelDeduct(productId, count); if (updateCount ! 1) { // Cancel失敗也需要重試。但這里有個“空回滾”問題需要處理見下文。 log.error(TCC Cancel 失敗xid{}, xid); throw new RuntimeException(Cancel釋放庫存失敗); } // 3. 更新日志表狀態(tài)為 cancel // tccLogService.updateStatus(xid, branchId, cancel); log.info(TCC Cancel 成功。xid{}, xid); return true; } }實現(xiàn)要點與坑點數(shù)據(jù)庫操作Try階段是凍結(jié)Confirm是扣減凍結(jié)值Cancel是釋放凍結(jié)值。這三個操作必須是冪等的。這意味著即使網(wǎng)絡(luò)超時導(dǎo)致TC重復(fù)調(diào)用執(zhí)行多次也不會對數(shù)據(jù)狀態(tài)產(chǎn)生錯誤影響。上面的代碼通過“冪等性檢查”和“基于狀態(tài)的更新”如update table set frozen frozen - #{count} where product_id #{id} and frozen #{count}來保證。業(yè)務(wù)上下文BusinessActionContext是框架在Try階段幫你保存的參數(shù)包在Confirm/Cancel階段自動注入。務(wù)必用BusinessActionContextParameter注解標(biāo)記所有Cancel階段需要的參數(shù)。本地事務(wù)每個TCC方法prepare, commit, cancel都標(biāo)注了Transactional。這是因為每個階段本身可能包含多個數(shù)據(jù)庫操作需要保證其原子性。Seata的全局事務(wù)是由這些本地事務(wù)組合而成的。日志表強(qiáng)烈建議建立一張獨立的TCC事務(wù)日志表。記錄xid全局事務(wù)ID、branchId分支事務(wù)ID、業(yè)務(wù)鍵、狀態(tài)try/commit/cancel、創(chuàng)建時間。它的作用巨大冪等控制在Confirm/Cancel前先查日志避免重復(fù)執(zhí)行。問題排查當(dāng)出現(xiàn)異常時可以通過日志還原事務(wù)執(zhí)行鏈路。防懸掛配合“空回滾”檢查。4. 發(fā)起與管控全局事務(wù)TM的角色庫存服務(wù)的TCC接口準(zhǔn)備好了現(xiàn)在需要在訂單服務(wù)事務(wù)管理器TM中發(fā)起并管理這個全局事務(wù)。在訂單服務(wù)的業(yè)務(wù)方法上使用GlobalTransactional注解即可開啟一個Seata全局事務(wù)。Service public class OrderServiceImpl implements OrderService { Autowired private InventoryTccAction inventoryTccAction; // 通過Feign或Dubbo引入的遠(yuǎn)程TCC接口代理 Autowired private OrderMapper orderMapper; Override GlobalTransactional(name createOrder, timeoutMills 60000, rollbackFor Exception.class) public Order createOrder(OrderDTO orderDTO) { // 1. 創(chuàng)建訂單本地事務(wù) Order order new Order(); // ... 設(shè)置訂單屬性 orderMapper.insert(order); // 2. 調(diào)用庫存服務(wù)執(zhí)行TCC Try階段 BusinessActionContext context new BusinessActionContext(); context.setActionName(inventoryTccAction); // 這里實際是通過RPC框架如Feign調(diào)用了 inventoryTccAction.prepare(context, ...) boolean tryResult inventoryTccAction.prepare(context, orderDTO.getProductId(), orderDTO.getCount()); if (!tryResult) { throw new RuntimeException(庫存預(yù)留失敗); } // 注意Try階段只是預(yù)留資源訂單創(chuàng)建和庫存預(yù)留都未最終提交。 // 3. 這里可以繼續(xù)調(diào)用其他TCC服務(wù)比如扣減積分、優(yōu)惠券... // 如果所有Try都成功GlobalTransactional 注解的方法正常結(jié)束Seata會自動觸發(fā)所有參與者的Confirm階段。 // 如果此處拋出異常Seata會自動觸發(fā)所有參與者的Cancel階段。 return order; } }TM端的關(guān)鍵點GlobalTransactional這是TM的標(biāo)識。它會在方法開始時向TC申請一個全局事務(wù)IDXID并將其通過線程上下文傳播到所有遠(yuǎn)程調(diào)用中。超時控制timeoutMills很重要。它定義了整個全局事務(wù)的超時時間。如果超過這個時間事務(wù)還未完成所有分支未到達(dá)終態(tài)TC會主動發(fā)起回滾。需要根據(jù)業(yè)務(wù)鏈路的復(fù)雜度合理設(shè)置。異?；貪L默認(rèn)情況下只有RuntimeException和Error會觸發(fā)回滾。如果你希望受檢異常也回滾需要使用rollbackFor屬性指定。RPC調(diào)用調(diào)用inventoryTccAction.prepare看起來是本地調(diào)用但實際上它應(yīng)該是一個遠(yuǎn)程服務(wù)的代理。你需要通過Feign或Dubbo將InventoryTccAction接口暴露為遠(yuǎn)程服務(wù)并在訂單服務(wù)中通過FeignClient等方式引入。Seata的TCC組件會自動攔截這個調(diào)用將其注冊為一個分支事務(wù)到TC。5. 生產(chǎn)環(huán)境避坑指南空回滾、冪等與懸掛如果只是跑通Demo上面的知識就夠了。但一旦上生產(chǎn)你會遇到幾個經(jīng)典的“坑”。不處理好它們分布式事務(wù)的可靠性無從談起。5.1 空回滾Empty Rollback問題描述一個分支事務(wù)的Try方法因網(wǎng)絡(luò)超時等原因根本沒有執(zhí)行但TM卻發(fā)起了全局回滾導(dǎo)致TC調(diào)用了該分支的Cancel方法。后果Cancel方法執(zhí)行了“釋放凍結(jié)資源”的操作但Try根本沒凍結(jié)過任何資源。這可能導(dǎo)致數(shù)據(jù)不一致比如庫存被錯誤地增加了。解決方案在Cancel方法中必須進(jìn)行空回滾判斷。Override public boolean cancel(BusinessActionContext actionContext) { String xid actionContext.getXid(); Long branchId actionContext.getBranchId(); // 1. 查詢事務(wù)日志表判斷Try是否執(zhí)行過 TccLog tccLog tccLogService.getByXidAndBranchId(xid, branchId); if (tccLog null) { // Try沒執(zhí)行過是空回滾 log.warn(收到空回滾請求xid{}, branchId{}. 插入一條取消記錄防止懸掛。, xid, branchId); // 插入一條狀態(tài)為‘cancel’的記錄目的是為了“占位”防止后續(xù)的懸掛問題 tccLogService.insertCancelLog(xid, branchId, productId, count); return true; // 空回滾直接返回成功 } // 2. 如果已經(jīng)執(zhí)行過Cancel冪等返回 if (cancel.equals(tccLog.getStatus())) { return true; } // 3. 正常執(zhí)行Cancel邏輯... }核心就是Cancel時檢查Try是否已執(zhí)行。沒執(zhí)行過就是空回滾記錄一條Cancel日志后直接返回不執(zhí)行業(yè)務(wù)邏輯。5.2 冪等控制Idempotence問題描述由于網(wǎng)絡(luò)抖動或TC重試機(jī)制Confirm或Cancel接口可能會被重復(fù)調(diào)用。后果如果不做冪等重復(fù)的Confirm會導(dǎo)致資源被多次扣減重復(fù)的Cancel會導(dǎo)致資源被多次釋放。解決方案利用事務(wù)日志表實現(xiàn)冪等。在Try成功后插入一條狀態(tài)為try的記錄。在Confirm/Cancel執(zhí)行前先查日志。如果狀態(tài)已經(jīng)是commit/cancel則直接返回成功。執(zhí)行完Confirm/Cancel業(yè)務(wù)邏輯后更新日志狀態(tài)為commit/cancel。所有數(shù)據(jù)庫更新操作盡量使用帶狀態(tài)的更新語句例如-- Confirm: 扣減凍結(jié)值同時確保凍結(jié)值足夠 UPDATE inventory SET frozen frozen - #{count}, total total - #{count} WHERE product_id #{productId} AND frozen #{count}; -- Cancel: 釋放凍結(jié)值同時確保凍結(jié)值足夠 UPDATE inventory SET frozen frozen - #{count}, available available #{count} WHERE product_id #{productId} AND frozen #{count};這樣即使重復(fù)執(zhí)行只要條件不滿足影響行數(shù)就是0不會破壞數(shù)據(jù)。5.3 懸掛Hanging問題描述空回滾發(fā)生后之前被阻塞的Try請求終于到達(dá)了服務(wù)端并執(zhí)行成功。后果Try在Cancel之后執(zhí)行導(dǎo)致資源被凍結(jié)但再也沒有Confirm或Cancel來釋放它了因為全局事務(wù)已結(jié)束造成資源永久鎖定。解決方案在Try方法中進(jìn)行懸掛判斷。Override public boolean prepare(BusinessActionContext actionContext, String productId, Integer count) { String xid actionContext.getXid(); Long branchId actionContext.getBranchId(); // 懸掛檢查在執(zhí)行業(yè)務(wù)前先查日志 TccLog tccLog tccLogService.getByXidAndBranchId(xid, branchId); if (tccLog ! null cancel.equals(tccLog.getStatus())) { // 發(fā)現(xiàn)已經(jīng)有一條Cancel日志說明發(fā)生了空回滾且Cancel先于Try到達(dá) log.warn(檢測到懸掛Try方法被拒絕執(zhí)行。xid{}, branchId{}, xid, branchId); return true; // 或者拋出一個特定的異常讓TM感知 } // ... 正常的Try業(yè)務(wù)邏輯 // 執(zhí)行業(yè)務(wù)后插入狀態(tài)為‘try’的日志 tccLogService.insertTryLog(xid, branchId, productId, count); return true; }核心是Try執(zhí)行前檢查是否已有對應(yīng)xid和branchId的Cancel記錄。如果有說明是懸掛應(yīng)拒絕執(zhí)行Try業(yè)務(wù)邏輯?？栈貪L、冪等、懸掛這三個問題是TCC模式在生產(chǎn)環(huán)境落地必須解決的“三座大山”。解決它們的核心工具就是那張TCC事務(wù)日志表。通過它記錄狀態(tài)所有操作都變成“先查后改”的模式從而保證最終一致性。6. 進(jìn)階話題嵌套調(diào)用、并發(fā)與監(jiān)控解決了基本可靠性問題我們再看一些更復(fù)雜的場景。6.1 嵌套的TCC調(diào)用有時候一個TCC服務(wù)內(nèi)部需要調(diào)用另一個TCC服務(wù)。比如“創(chuàng)建訂單”事務(wù)中調(diào)用“庫存服務(wù)”的TCC接口而“庫存服務(wù)”的Try操作里又需要調(diào)用“倉儲服務(wù)”的TCC接口來鎖定庫位。Seata是支持這種嵌套的。關(guān)鍵在于XID的傳遞。只要確保RPC框架如Dubbo、Feign的過濾器正確地將當(dāng)前線程上下文中的XID傳遞到下游服務(wù)Seata就能自動識別并管理這個嵌套分支事務(wù)。它會形成一個調(diào)用樹TC會確保所有分支包括嵌套的一起提交或回滾。在代碼上不需要特殊處理只需確保每個服務(wù)都正確引入了Seata客戶端并配置了事務(wù)組。6.2 高并發(fā)下的資源競爭在TCC的Try階段我們經(jīng)常要“凍結(jié)”資源。在高并發(fā)場景下對同一條記錄比如同一商品庫存的凍結(jié)操作可能發(fā)生沖突。解決方案數(shù)據(jù)庫悲觀鎖在Try方法的SQL中使用SELECT ... FOR UPDATE先鎖定記錄再執(zhí)行更新。但這會嚴(yán)重影響性能。樂觀鎖在庫存表中增加一個版本號字段。Try操作時使用UPDATE ... SET frozen frozen #{count}, version version 1 WHERE id #{id} AND version #{oldVersion}。如果更新失敗影響行數(shù)為0說明發(fā)生了并發(fā)沖突可以重試或直接返回失敗。分布式鎖在進(jìn)入Try業(yè)務(wù)邏輯前用Redis或Zookeeper對業(yè)務(wù)鍵如lock:inventory:{productId}加鎖。這是最常用的方式但要注意鎖的粒度、超時時間和釋放的可靠性。我個人更傾向于“樂觀鎖 有限重試”或“細(xì)粒度分布式鎖”的組合。在庫存凍結(jié)場景可以在應(yīng)用層用Redis分布式鎖控制同一商品ID的并發(fā)然后在數(shù)據(jù)庫層用樂觀鎖做最終保障。6.3 監(jiān)控與排查當(dāng)TCC事務(wù)出現(xiàn)問題時排查鏈路比普通調(diào)用復(fù)雜。你需要關(guān)注幾個點Seata TC控制臺訪問http://tc-server:7091查看全局事務(wù)列表。你可以看到每個全局事務(wù)的XID、狀態(tài)、開始時間、耗時以及其下所有分支事務(wù)的狀態(tài)。這是最直觀的定位工具。業(yè)務(wù)日志在TCC接口的三個方法中務(wù)必打印包含XID和BranchId的日志。這是串聯(lián)整個事務(wù)鏈路的唯一標(biāo)識。通過ELK或類似的日志聚合系統(tǒng)用XID可以輕松搜出該事務(wù)在所有微服務(wù)中的執(zhí)行痕跡。事務(wù)日志表你業(yè)務(wù)庫里的那張TCC日志表是最終的證據(jù)。通過它可以清楚地看到每個分支事務(wù)走到了哪一步try/commit/cancel以及執(zhí)行時間。如果發(fā)現(xiàn)一個事務(wù)長時間處于“try”狀態(tài)那很可能發(fā)生了懸掛如果大量“cancel”日志沒有對應(yīng)的“try”日志那可能是空回滾頻發(fā)需要檢查網(wǎng)絡(luò)或超時配置。Metrics監(jiān)控Seata客戶端會暴露一些Metrics需要額外配置比如全局事務(wù)提交/回滾次數(shù)、分支事務(wù)注冊次數(shù)、各種模式的耗時等?？梢越尤隤rometheus和Grafana對分布式事務(wù)的健康度進(jìn)行監(jiān)控和告警。7. 總結(jié)與個人體會走完這一整套流程從環(huán)境搭建、代碼編寫到填坑進(jìn)階你應(yīng)該對Seata TCC模式有了比較立體的認(rèn)識。它不是銀彈需要你付出額外的設(shè)計設(shè)計TCC接口和資源預(yù)留邏輯和編碼實現(xiàn)三階段方法成本。但換來的是對復(fù)雜業(yè)務(wù)場景更強(qiáng)的掌控力以及對異構(gòu)數(shù)據(jù)源的支持。我個人在項目中的體會是設(shè)計階段多花時間在寫代碼前一定要和業(yè)務(wù)方、架構(gòu)師一起把每個分布式事務(wù)的邊界、每個參與服務(wù)的Try/Confirm/Cancel具體操作畫清楚。特別是資源預(yù)留的粒度是鎖整條記錄還是鎖部分字段這直接影響并發(fā)性能。日志表是生命線那張小小的TCC事務(wù)日志表在開發(fā)和排查階段的價值遠(yuǎn)超你的想象。一定要建而且要設(shè)計好查詢索引xid, branch_id, status, create_time。超時時間要合理全局事務(wù)超時時間timeoutMills不能設(shè)得太短否則長鏈路業(yè)務(wù)容易超時回滾也不能設(shè)得太長否則出問題時資源鎖定時間過長。需要根據(jù)壓測和線上監(jiān)控來調(diào)整。做好降級和熔斷分布式事務(wù)框架本身也可能成為故障點。如果TC集群不可用你的業(yè)務(wù)應(yīng)該有降級方案比如切到基于消息的最終一致性或者記錄異常工單人工處理。在調(diào)用TCC服務(wù)時也要配置好Feign/Dubbo的超時和熔斷避免一個分支事務(wù)的阻塞拖垮整個全局事務(wù)。最后TCC模式的思想——先試探后確認(rèn)——其實是一種非常普適的解決分布式問題的思路。即使未來你不使用Seata這種通過業(yè)務(wù)日志和狀態(tài)機(jī)來實現(xiàn)最終一致性的模式在設(shè)計和處理復(fù)雜業(yè)務(wù)邏輯時依然會給你帶來啟發(fā)。