分布式系统里最让人头疼的场景之一就是一笔业务横跨多个服务、每个服务各自管着自己的数据库结果中间某个环节挂了前面已经落库的数据怎么办。本地事务那套 ACID 到了这里直接失效数据库帮不了你只能靠业务层面自己兜底。TCC 补偿模式就是在这个背景下被反复拿出来讨论的一套解法它不依赖数据库的全局锁也不要求所有参与者支持 XA而是把提交这件事拆成预留资源—确认—撤销三段用业务代码把一致性责任扛起来。这篇内容适合已经了解分布式事务基本概念、正在为跨服务数据一致性发愁的后端开发看也适合想搞清楚 TCC 到底难在哪、值不值得用的技术负责人参考。我会从它解决的问题讲起把 Try-Confirm-Cancel 三个阶段的职责边界、空回滚与悬挂这两个经典坑、幂等设计的落地方式、以及和生产环境打交道时那些文档里不会写的细节尽量掰开揉碎说清楚。1. TCC 到底在补偿什么从一次跨服务扣款说起很多人第一次接触 TCC是被补偿两个字带偏的以为它就是失败了再反向操作一把。这个理解只对了一半真正让 TCC 站得住脚的是它把资源的占用和资源的最终归属拆成了两个时间点。要讲清楚这件事得先看一个具体场景。1.1 一个订单场景暴露的本地事务边界假设一个下单链路涉及三个服务订单服务创建订单、库存服务扣减库存、账户服务扣减余额。如果这三个操作在同一个数据库里一个本地事务包住就完事了任何一步失败整体回滚。但现实是它们分属三个独立部署的服务各自连着自己的库本地事务的边界到单个服务为止跨不过去。这时候最朴素的做法是依次调用失败就反向调用补偿接口。听起来简单问题在于如果库存扣减成功了账户扣减却超时了你根本不知道账户那边到底扣没扣——超时不等于失败可能只是响应慢实际已经落库。你贸然去补偿库存结果账户那边其实也成功了数据就错乱了。这就是分布式场景下最典型的状态不确定问题也是所有分布式事务方案要正面硬刚的核心矛盾。TCC 的思路不是去消除这种不确定性而是承认它存在然后用一套约定把不确定性关进笼子里。它要求每个参与方都实现三个接口Try 阶段做资源检查和预留Confirm 阶段做真正的业务确认Cancel 阶段做预留资源的释放。关键在于Try 阶段执行完资源就已经被锁定了别的请求抢不走但还没有真正生效只有 Confirm 之后才算数。1.2 Try-Confirm-Cancel 三段的职责划分把三个阶段拆开看各自的职责其实非常清晰但很多人落地时容易混淆导致后面一堆问题。阶段核心动作资源状态失败后的处理Try检查并预留资源冻结/预占未生效由协调者发起 CancelConfirm确认使用预留资源正式生效必须成功靠重试保证Cancel释放预留资源回到初始态必须成功靠重试保证Try 阶段是整个 TCC 的地基。它要做两件事一是业务层面的合法性校验比如库存够不够、余额足不足二是把资源冻起来。以库存为例不是直接减库存而是把可用库存转到冻结库存可用库存减少、冻结库存增加总库存不变。这一步做完即使后面别的请求进来也抢不走这部分资源因为可用库存已经不够了。Confirm 阶段是把冻结的资源真正消耗掉冻结库存减少相当于完成出库。这一步理论上不会失败因为资源在 Try 阶段已经预留好了但工程上必须假设它会失败——网络抖动、服务重启都可能让 Confirm 调用失败所以 Confirm 必须支持重试且重试要幂等。Cancel 阶段是把冻结的资源还回去冻结库存转回可用库存。它同样必须支持重试和幂等。这里有个容易被忽略的点Cancel 和 Confirm 是互斥的一笔事务要么最终 Confirm要么最终 Cancel不会两个都执行协调者要保证这个语义。提示Try 阶段预留资源时一定要用冻结这种中间状态而不是直接扣减。直接扣减的话一旦后续要 Cancel你没法区分这笔扣减是本次事务的还是别的正常业务的补偿就无从下手。1.3 为什么不能简单用反向操作代替预留有人会问我 Try 阶段直接扣库存Cancel 阶段加回来不就行了何必搞个冻结状态。这个想法在小流量、低并发下能跑通但一旦并发上来就会出问题。设想库存只剩 1 件两个请求同时进来。如果 Try 直接扣减第一个请求扣成功库存变 0第二个请求校验发现库存不足直接失败看起来没问题。但如果第一个请求后续 Cancel 了库存加回 1这时候第二个请求早就失败了用户看到的是没货实际上货又回来了体验和数据都对不上。更麻烦的是如果 Cancel 加回来的时候正好有第三个请求在扣减加和减的顺序一乱库存可能变成负数或者凭空多出来。用冻结状态就没这个问题Try 阶段把可用库存转到冻结可用库存变 0第二个请求看到可用不足直接失败这是符合预期的第一个请求 Cancel 时把冻结转回可用库存恢复逻辑自洽。冻结状态本质上是一个隔离带把未决事务的影响限制在冻结池里不影响可用资源的判断。这也是 TCC 相比裸补偿更严谨的地方。2. 空回滚与悬挂TCC 落地绕不开的两个坑TCC 的理论模型很干净但一上生产就会遇到两个经典异常空回滚和悬挂。这两个词听着玄乎本质都是网络不可靠导致的时序错乱。搞不清楚它们你的 Cancel 逻辑迟早会把数据搞坏。2.1 空回滚是怎么产生的空回滚指的是Cancel 执行了但对应的 Try 根本没执行成功。听起来矛盾——没 Try 成功怎么会触发 Cancel但在分布式调用里这太常见了。典型链路是这样的协调者调用参与方的 Try 接口这个请求因为网络问题超时了协调者判定 Try 失败于是发起 Cancel。但实际上那个 Try 请求可能压根没到达参与方网络丢包也可能到达了但参与方处理到一半挂了。无论哪种情况参与方这边都没有完成资源预留可 Cancel 请求却来了。如果 Cancel 逻辑不假思索地执行冻结转可用就会把本来不属于这笔事务的资源给释放了凭空多出库存数据直接错乱。所以 Cancel 接口必须能识别我到底有没有做过 Try。做法是在 Try 阶段落一条事务记录Cancel 进来先查这条记录如果记录不存在或者状态是未预留说明 Try 没成功直接返回成功即可不做任何资源操作。这条记录就是防空回滚的关键业内常说的事务控制表就是干这个的。2.2 悬挂Cancel 比 Try 先到悬挂比空回滚更隐蔽。它的场景是Try 请求因为网络延迟迟迟没到参与方协调者等不及超时了先发了 CancelCancel 执行完此时因为没 Try 记录走了空回滚逻辑直接返回成功结果那个迟到的 Try 请求这才到达参与方参与方一看没有事务记录当成新事务处理把资源给预留了。这下坏了这笔事务的 Cancel 已经执行过了不会再来了可 Try 却预留了资源这部分资源永远冻结着没人释放成了悬挂的僵尸资源。时间一长冻结池越积越多可用资源越来越少系统慢慢就废了。防悬挂的核心是让 Try 能识别这笔事务是不是已经被 Cancel 过了。常见做法是在 Cancel 时也落一条记录标记为已回滚Try 进来先查如果发现这笔事务已经有回滚记录说明 Cancel 先到了Try 直接拒绝执行不再预留资源。这样迟到的 Try 就被挡在门外不会产生悬挂。2.3 用一张状态表同时挡住两个坑空回滚和悬挂看似是两个问题其实可以用同一张事务控制表解决关键是把事务的每个阶段状态都记下来。我一般会设计成这样的结构CREATE TABLE tcc_transaction ( tx_id VARCHAR(64) PRIMARY KEY, -- 全局事务ID branch_id VARCHAR(64) NOT NULL, -- 分支事务ID status TINYINT NOT NULL, -- 1:TRY成功 2:CONFIRM成功 3:CANCEL成功 4:已回滚(防悬挂) create_time DATETIME NOT NULL, update_time DATETIME NOT NULL, UNIQUE KEY uk_branch (branch_id) );Try 进来先按 branch_id 查有记录且状态是已回滚说明 Cancel 先到直接拒绝防悬挂没记录插入一条 TRY 成功记录并预留资源。Cancel 进来先查没记录插入一条已回滚记录并直接返回成功防空回滚同时这条记录还能挡住后续迟到的 Try有 TRY 记录执行资源释放并更新为 CANCEL 成功。这里有个细节值得说插入已回滚记录和判断是否已回滚必须是原子的否则并发下两个 Cancel 同时进来都判断没记录会重复插入。用 branch_id 做唯一索引靠数据库的唯一约束兜底是最省事的做法插入冲突就说明已经处理过了直接返回成功即可。注意状态表里的 branch_id 唯一约束是防并发的最后一道防线别省。我见过为了性能去掉唯一索引、改用先查后插的实现高并发下重复 Cancel 直接把冻结库存释放了两次账对不上查了半天。3. 幂等、重试与超时让 Confirm 和 Cancel 真正可靠TCC 的协调者本质上是个死磕到底的角色Try 成功了就一定要 Confirm 成功Try 失败了就一定要 Cancel 成功中间不管遇到什么异常都靠重试硬扛。这就要求 Confirm 和 Cancel 接口必须能承受反复调用也就是幂等。这块做不好重试越多错得越离谱。3.1 幂等不是加个唯一索引就完事很多人对幂等的理解停留在数据库加唯一索引重复插入报错就忽略。这在简单场景下够用但 TCC 的 Confirm/Cancel 幂等要考虑的更多。以 Confirm 为例它的语义是把冻结资源转为正式消耗。如果重复执行冻结库存会被减两次直接减成负数。所以 Confirm 必须先判断这笔事务的 Confirm 是不是已经做过了。判断依据还是那张状态表Confirm 进来先查状态如果已经是 CONFIRM 成功直接返回成功不做任何资源操作如果是 TRY 成功执行资源扣减并更新状态如果状态是 CANCEL 成功说明事务已经回滚了这时候再来 Confirm 属于异常应该拒绝并告警。Cancel 同理已经是 CANCEL 成功就直接返回是 TRY 成功就释放资源并更新是 CONFIRM 成功则拒绝。这里的状态判断和资源操作必须在同一个本地事务里完成否则判断完还没更新状态就挂了下次重试又会重复操作。用本地事务包住查状态—改资源—改状态三步是保证幂等的基本功。3.2 重试策略别用固定间隔死磕Confirm 和 Cancel 的重试不是简单加个 for 循环就行。固定间隔重试在服务短暂抖动时可能连续失败等抖动过去重试次数已经耗尽了而间隔太长又会让事务长时间处于中间态资源一直被占着。我一般用指数退避加最大次数限制第一次失败等 1 秒第二次 2 秒第三次 4 秒依次翻倍封顶到比如 5 分钟一次总重试次数设个上限比如 15 次覆盖大约几小时。超过上限还没成功就把这笔事务标记为待人工介入落一条告警让运维或开发去查。千万别无限重试否则一个坏掉的分支会拖垮整个协调者的线程池。重试还有个坑重试的请求必须带同样的全局事务 ID 和分支 ID不能每次重试生成新 ID否则参与方那边根本认不出这是同一笔事务幂等判断全失效。协调者要把事务上下文持久化下来重启后还能接着重试这也是为什么协调者自己也需要一张事务表。3.3 超时时间怎么定才不坑自己Try 的超时时间设置是个技术活。设太短正常慢请求被误判失败触发不必要的 Cancel白白浪费资源预留设太长真出问题时协调者要等很久才发现事务中间态持续时间过长冻结资源迟迟不释放。我的经验是Try 超时 参与方 Try 接口 P99 耗时 × 2 到 3 倍。比如库存服务 Try 的 P99 是 50ms那超时设 150ms 左右比较合理既给了正常波动空间又不会等太久。同时参与方内部也要设自己的超时比如 Try 里查库存、更新冻结库存这些操作各自设超时避免单个慢查询把整个 Try 拖死。Confirm 和 Cancel 的超时可以设得比 Try 长一些因为它们不涉及复杂的业务校验主要是资源操作但也不能无限长。另外协调者调用参与方的超时和参与方内部操作的超时要分层设置外层比内层大否则外层超时了内层还在跑容易产生协调者以为失败、参与方其实成功的错位。4. 从代码看 TCCTry、Confirm、Cancel 的落地写法光讲理论容易飘落到代码上才知道哪里会卡。下面用库存服务为例把三个接口的实现骨架和关键判断写出来重点看状态流转和幂等处理。4.1 Try 接口先查状态再预留Try 的核心是防悬挂 预留资源顺序不能乱。先查事务记录确认不是已回滚状态再执行预留。public boolean tryReserve(String txId, String branchId, Long skuId, int count) { // 1. 防悬挂先查是否已有回滚记录 TccRecord record tccMapper.selectByBranchId(branchId); if (record ! null record.getStatus() STATUS_ROLLBACKED) { // Cancel 先到了拒绝预留 return false; } if (record ! null record.getStatus() STATUS_TRY_SUCCESS) { // 重复 Try直接返回成功幂等 return true; } // 2. 本地事务插入 TRY 记录 冻结库存 return transactionTemplate.execute(status - { tccMapper.insertTryRecord(txId, branchId); int affected stockMapper.freezeStock(skuId, count); if (affected 0) { // 可用库存不足回滚本地事务 status.setRollbackOnly(); return false; } return true; }); }这里freezeStock的 SQL 要带条件类似UPDATE stock SET available available - #{count}, frozen frozen #{count} WHERE sku_id #{skuId} AND available #{count}靠available count这个条件保证不会超卖affected 为 0 就说明库存不够。把判断和更新放在一条 SQL 里避免先查后改的并发窗口。4.2 Confirm 接口状态机驱动拒绝非法流转Confirm 只认 TRY 成功这个前置状态其他状态一律按幂等或异常处理。public boolean confirm(String txId, String branchId, Long skuId, int count) { TccRecord record tccMapper.selectByBranchId(branchId); if (record null) { // 没有 Try 记录却来 Confirm属于异常告警 alertService.warn(confirm without try, branchId); return false; } if (record.getStatus() STATUS_CONFIRM_SUCCESS) { return true; // 幂等 } if (record.getStatus() ! STATUS_TRY_SUCCESS) { // 已回滚或其他状态拒绝 return false; } return transactionTemplate.execute(status - { // 冻结库存转出库冻结减少总库存实际减少 stockMapper.confirmStock(skuId, count); tccMapper.updateStatus(branchId, STATUS_CONFIRM_SUCCESS); return true; }); }confirmStock的 SQL 是UPDATE stock SET frozen frozen - #{count} WHERE sku_id #{skuId} AND frozen #{count}同样带条件防止冻结被减成负数。状态更新和资源操作在同一个本地事务里保证要么都成功要么都失败。4.3 Cancel 接口空回滚判断是第一步Cancel 要先处理没 Try 记录的情况这是防空回滚的关键。public boolean cancel(String txId, String branchId, Long skuId, int count) { TccRecord record tccMapper.selectByBranchId(branchId); if (record null) { // 空回滚Try 没成功插入回滚记录挡住后续迟到的 Try try { tccMapper.insertRollbackRecord(txId, branchId); } catch (DuplicateKeyException e) { // 并发下已被别的 Cancel 插入忽略 } return true; } if (record.getStatus() STATUS_CANCEL_SUCCESS) { return true; // 幂等 } if (record.getStatus() ! STATUS_TRY_SUCCESS) { return false; } return transactionTemplate.execute(status - { stockMapper.cancelStock(skuId, count); // 冻结转回可用 tccMapper.updateStatus(branchId, STATUS_CANCEL_SUCCESS); return true; }); }注意空回滚分支里插入回滚记录用了 try-catch 捕获唯一键冲突这是并发 Cancel 同时进来的兜底。cancelStock的 SQL 是UPDATE stock SET available available #{count}, frozen frozen - #{count} WHERE sku_id #{skuId} AND frozen #{count}冻结不足说明数据已经不一致了affected 为 0 要告警。4.4 三个接口的公共约束把上面三段代码的共同点拎出来其实是几条硬约束所有状态判断和资源操作必须在同一个本地事务里所有资源更新的 SQL 都要带条件available count或frozen count防止减成负数所有接口都要先查状态表再决定动作所有异常分支都要有告警别静默吞掉。这几条看着琐碎但少一条就可能在某个边界场景下把数据搞坏。5. 协调者视角全局事务怎么串起来参与方把三个接口实现好只是半件事另一半在协调者身上。协调者负责发起 Try、根据结果决定 Confirm 还是 Cancel、以及在这些动作失败时重试。它的可靠性直接决定整个 TCC 能不能跑稳。5.1 协调者的状态机设计协调者自己也要维护全局事务的状态一般有这几个TRYING正在执行 Try、CONFIRMING正在 Confirm、CANCELING正在 Cancel、FINISHED已完成。发起一笔事务时先落一条 TRYING 记录然后依次调用各参与方的 Try全部成功就转 CONFIRMING 并逐个 Confirm任一失败就转 CANCELING 并逐个 Cancel。这里的关键是协调者的状态变更也要持久化且和调用参与方的动作要有明确的先后。常见做法是先落状态再调用比如决定要 Cancel 了先把全局状态改成 CANCELING 落库再去调各参与方的 Cancel。这样即使协调者中途挂了重启后扫到 CANCELING 状态的事务能接着把没 Cancel 完的分支补上。如果反过来先调用再落状态挂了之后根本不知道这笔事务进行到哪了。5.2 分支事务的补偿顺序一笔全局事务有多个分支时Cancel 的顺序其实有讲究。理论上 TCC 的 Cancel 是各自独立的顺序不影响正确性因为每个分支只释放自己的预留资源。但工程上我倾向于按 Try 的逆序 Cancel原因是业务上往往有依赖关系——比如先扣库存再扣余额Cancel 时先还余额再还库存更符合业务直觉出问题时排查也顺。Confirm 的顺序则没那么讲究因为 Confirm 是确认消耗各分支互不影响并行调用都行。不过并行 Confirm 要注意控制并发度别一下子把下游打满我一般用个小线程池限制同时 Confirm 的分支数。5.3 协调者高可用不能只靠单机协调者如果是单点它挂了整个 TCC 就停摆。生产上协调者一般要做成集群但集群带来一个新问题同一笔事务不能被两个协调者同时处理否则重复 Confirm/Cancel。解决办法是给全局事务加锁比如用数据库的行锁或者分布式锁处理某笔事务前先抢锁抢到才处理。另一个思路是把协调者的重试逻辑做成扫描 认领模式后台线程定期扫状态表里处于中间态TRYING/CONFIRMING/CANCELING且超过一定时间没更新的事务认领后继续推进。认领用乐观锁带版本号更新保证只有一个线程能拿到。这种模式天然支持多实例部署挂了一个还有别的接着扫。6. TCC 的适用边界什么场景该用什么场景别硬上TCC 不是银弹它对业务的侵入性很强——每个参与方都要改造成三个接口还要维护状态表、处理幂等和异常。用错场景改造成本和维护负担会压垮团队。6.1 适合 TCC 的三类场景第一类是资金类业务比如支付、转账、账户扣款。这类业务对一致性要求极高且天然适合冻结—确认模型付款方先冻结金额收款方确认后再真正划转中间任何一步失败都能把冻结金额解冻资金不会凭空消失。银行和支付机构大量用这个模式不是没道理的。第二类是库存类业务尤其是秒杀、抢购这种高并发场景。Try 阶段冻结库存能有效防止超卖Confirm 阶段完成出库Cancel 阶段释放冻结。相比直接扣减再补偿冻结模型在并发下更稳。第三类是资源预订类比如机票座位、酒店房间、优惠券锁定。这类业务的共性是资源有限且需要临时占用和 TCC 的预留语义高度契合。6.2 不适合硬上 TCC 的情况如果业务本身对一致性要求没那么高比如发个通知、记个日志用 TCC 就是杀鸡用牛刀消息队列的最终一致性方案更轻量。如果参与方是第三方系统、你改不了它的接口那也没法做 TCC只能靠对账或者补偿任务兜底。还有一种情况要特别小心参与方的业务逻辑本身不支持预留语义。比如某个操作一旦执行就不可逆发了短信、调了外部接口你没法在 Try 阶段预留它这种就不适合 TCC。硬要套只能在 Try 阶段做校验、Confirm 阶段才真正执行但这样 Try 就没起到预留作用Confirm 失败时也没法补偿等于退化成两阶段提交的简化版可靠性打折扣。6.3 和 Saga、本地消息表的取舍TCC 常被拿来和 Saga、本地消息表比较。Saga 是长事务拆分每个步骤都有对应的补偿操作适合流程长、步骤多的业务但它的补偿是反向操作不像 TCC 有预留隔离中间态可能被其他请求看到。本地消息表靠消息队列保证最终一致实现简单但只保证最终中间可能长时间不一致且不适合强一致的资源扣减。我的取舍逻辑是需要强一致且资源可预留选 TCC流程长、步骤多、能接受最终一致选 Saga只是异步通知、对实时性要求不高选本地消息表。没有哪个方案通吃关键是看业务对一致性的真实要求和参与方的改造能力。7. 生产环境里那些文档不会写的细节理论讲完最后聊几个真正踩过才知道的坑。这些细节在方案文档里基本看不到但每一条都可能在某个深夜把你叫起来。7.1 冻结资源的对账不能省TCC 跑久了冻结池里难免有对不上的账——可能是某次 Cancel 没执行完、可能是人工误操作、也可能是代码 bug。所以一定要有对账机制定期把冻结库存和状态表里处于 TRY 成功但长时间未 Confirm/Cancel 的记录做比对发现异常就告警。对账的粒度我一般按天做全量、按小时做增量。全量对账扫所有冻结记录增量对账只看最近一小时状态有变化的。对不上的记录先别急着自动修复人工确认后再处理自动修复一旦逻辑有误可能把小问题放大成大事故。7.2 状态表的清理策略状态表会随着事务量增长越来越大的不清理迟早拖慢查询。但清理有讲究不能删还在中间态的记录否则重试时找不到状态幂等就失效了。我的做法是只清理处于终态CONFIRM 成功、CANCEL 成功、已回滚且超过一定时间比如 7 天的记录中间态的一律保留。清理用分批删除别一次性 delete 太多导致锁表。可以按 create_time 范围分批每批几千条删完 sleep 一下再删下一批。另外清理前最好先归档到历史表万一后面要查历史事务还有据可查。7.3 监控指标要盯住这几个TCC 的监控不能只看接口成功率有几个指标必须单独盯中间态事务的数量和持续时间TRYING/CONFIRMING/CANCELING 状态的事务如果持续增长说明有分支卡住了、Confirm/Cancel 的重试次数分布重试次数异常高说明下游不稳、空回滚和悬挂的触发次数这两个指标一旦非零就要查原因、冻结资源的增长趋势持续增长说明有资源没释放。这些指标我一般配成告警中间态事务超过阈值、空回滚次数突增、冻结资源超过总量的一定比例都直接推告警。别等用户投诉了才发现问题那时候数据可能已经错乱了。7.4 灰度上线和回滚预案TCC 改造涉及核心链路千万别一把梭全量上线。我的做法是先选一个非核心的、流量小的业务做试点跑一两周观察对账和监控都正常再逐步扩大范围。灰度期间要保留旧逻辑的开关出问题能快速切回去。回滚预案也要提前想好如果 TCC 上线后发现严重问题怎么回退已经产生的冻结资源怎么处理这些都要在上线前演练一遍。我见过没做回滚预案的团队上线出问题后手忙脚乱最后只能停服人工修数据代价极大。我个人在实际操作中的体会是TCC 的难点从来不在理论而在那些边角场景的工程处理——空回滚、悬挂、幂等、重试、对账每一个单独看都不复杂但组合起来就是一张需要仔细编织的网。把这张网织密了TCC 才能在生产环境里真正稳得住织不密它带来的麻烦可能比它解决的问题还多。所以每次决定用 TCC 之前我都会先问自己一句这个业务的参与方真的都能改造成支持预留语义吗想清楚这个问题再动手不迟。
分布式系统里最让人头疼的场景之一就是一笔业务横跨多个服务、每个服务各自管着自己的数据库结果中间某个环节挂了前面已经落库的数据怎么办。本地事务那套 ACID 到了这里直接失效数据库帮不了你只能靠业务层面自己兜底。TCC 补偿模式就是在这个背景下被反复拿出来讨论的一套解法它不依赖数据库的全局锁也不要求所有参与者支持 XA而是把提交这件事拆成预留资源—确认—撤销三段用业务代码把一致性责任扛起来。这篇内容适合已经了解分布式事务基本概念、正在为跨服务数据一致性发愁的后端开发看也适合想搞清楚 TCC 到底难在哪、值不值得用的技术负责人参考。我会从它解决的问题讲起把 Try-Confirm-Cancel 三个阶段的职责边界、空回滚与悬挂这两个经典坑、幂等设计的落地方式、以及和生产环境打交道时那些文档里不会写的细节尽量掰开揉碎说清楚。1. TCC 到底在补偿什么从一次跨服务扣款说起很多人第一次接触 TCC是被补偿两个字带偏的以为它就是失败了再反向操作一把。这个理解只对了一半真正让 TCC 站得住脚的是它把资源的占用和资源的最终归属拆成了两个时间点。要讲清楚这件事得先看一个具体场景。1.1 一个订单场景暴露的本地事务边界假设一个下单链路涉及三个服务订单服务创建订单、库存服务扣减库存、账户服务扣减余额。如果这三个操作在同一个数据库里一个本地事务包住就完事了任何一步失败整体回滚。但现实是它们分属三个独立部署的服务各自连着自己的库本地事务的边界到单个服务为止跨不过去。这时候最朴素的做法是依次调用失败就反向调用补偿接口。听起来简单问题在于如果库存扣减成功了账户扣减却超时了你根本不知道账户那边到底扣没扣——超时不等于失败可能只是响应慢实际已经落库。你贸然去补偿库存结果账户那边其实也成功了数据就错乱了。这就是分布式场景下最典型的状态不确定问题也是所有分布式事务方案要正面硬刚的核心矛盾。TCC 的思路不是去消除这种不确定性而是承认它存在然后用一套约定把不确定性关进笼子里。它要求每个参与方都实现三个接口Try 阶段做资源检查和预留Confirm 阶段做真正的业务确认Cancel 阶段做预留资源的释放。关键在于Try 阶段执行完资源就已经被锁定了别的请求抢不走但还没有真正生效只有 Confirm 之后才算数。1.2 Try-Confirm-Cancel 三段的职责划分把三个阶段拆开看各自的职责其实非常清晰但很多人落地时容易混淆导致后面一堆问题。阶段核心动作资源状态失败后的处理Try检查并预留资源冻结/预占未生效由协调者发起 CancelConfirm确认使用预留资源正式生效必须成功靠重试保证Cancel释放预留资源回到初始态必须成功靠重试保证Try 阶段是整个 TCC 的地基。它要做两件事一是业务层面的合法性校验比如库存够不够、余额足不足二是把资源冻起来。以库存为例不是直接减库存而是把可用库存转到冻结库存可用库存减少、冻结库存增加总库存不变。这一步做完即使后面别的请求进来也抢不走这部分资源因为可用库存已经不够了。Confirm 阶段是把冻结的资源真正消耗掉冻结库存减少相当于完成出库。这一步理论上不会失败因为资源在 Try 阶段已经预留好了但工程上必须假设它会失败——网络抖动、服务重启都可能让 Confirm 调用失败所以 Confirm 必须支持重试且重试要幂等。Cancel 阶段是把冻结的资源还回去冻结库存转回可用库存。它同样必须支持重试和幂等。这里有个容易被忽略的点Cancel 和 Confirm 是互斥的一笔事务要么最终 Confirm要么最终 Cancel不会两个都执行协调者要保证这个语义。提示Try 阶段预留资源时一定要用冻结这种中间状态而不是直接扣减。直接扣减的话一旦后续要 Cancel你没法区分这笔扣减是本次事务的还是别的正常业务的补偿就无从下手。1.3 为什么不能简单用反向操作代替预留有人会问我 Try 阶段直接扣库存Cancel 阶段加回来不就行了何必搞个冻结状态。这个想法在小流量、低并发下能跑通但一旦并发上来就会出问题。设想库存只剩 1 件两个请求同时进来。如果 Try 直接扣减第一个请求扣成功库存变 0第二个请求校验发现库存不足直接失败看起来没问题。但如果第一个请求后续 Cancel 了库存加回 1这时候第二个请求早就失败了用户看到的是没货实际上货又回来了体验和数据都对不上。更麻烦的是如果 Cancel 加回来的时候正好有第三个请求在扣减加和减的顺序一乱库存可能变成负数或者凭空多出来。用冻结状态就没这个问题Try 阶段把可用库存转到冻结可用库存变 0第二个请求看到可用不足直接失败这是符合预期的第一个请求 Cancel 时把冻结转回可用库存恢复逻辑自洽。冻结状态本质上是一个隔离带把未决事务的影响限制在冻结池里不影响可用资源的判断。这也是 TCC 相比裸补偿更严谨的地方。2. 空回滚与悬挂TCC 落地绕不开的两个坑TCC 的理论模型很干净但一上生产就会遇到两个经典异常空回滚和悬挂。这两个词听着玄乎本质都是网络不可靠导致的时序错乱。搞不清楚它们你的 Cancel 逻辑迟早会把数据搞坏。2.1 空回滚是怎么产生的空回滚指的是Cancel 执行了但对应的 Try 根本没执行成功。听起来矛盾——没 Try 成功怎么会触发 Cancel但在分布式调用里这太常见了。典型链路是这样的协调者调用参与方的 Try 接口这个请求因为网络问题超时了协调者判定 Try 失败于是发起 Cancel。但实际上那个 Try 请求可能压根没到达参与方网络丢包也可能到达了但参与方处理到一半挂了。无论哪种情况参与方这边都没有完成资源预留可 Cancel 请求却来了。如果 Cancel 逻辑不假思索地执行冻结转可用就会把本来不属于这笔事务的资源给释放了凭空多出库存数据直接错乱。所以 Cancel 接口必须能识别我到底有没有做过 Try。做法是在 Try 阶段落一条事务记录Cancel 进来先查这条记录如果记录不存在或者状态是未预留说明 Try 没成功直接返回成功即可不做任何资源操作。这条记录就是防空回滚的关键业内常说的事务控制表就是干这个的。2.2 悬挂Cancel 比 Try 先到悬挂比空回滚更隐蔽。它的场景是Try 请求因为网络延迟迟迟没到参与方协调者等不及超时了先发了 CancelCancel 执行完此时因为没 Try 记录走了空回滚逻辑直接返回成功结果那个迟到的 Try 请求这才到达参与方参与方一看没有事务记录当成新事务处理把资源给预留了。这下坏了这笔事务的 Cancel 已经执行过了不会再来了可 Try 却预留了资源这部分资源永远冻结着没人释放成了悬挂的僵尸资源。时间一长冻结池越积越多可用资源越来越少系统慢慢就废了。防悬挂的核心是让 Try 能识别这笔事务是不是已经被 Cancel 过了。常见做法是在 Cancel 时也落一条记录标记为已回滚Try 进来先查如果发现这笔事务已经有回滚记录说明 Cancel 先到了Try 直接拒绝执行不再预留资源。这样迟到的 Try 就被挡在门外不会产生悬挂。2.3 用一张状态表同时挡住两个坑空回滚和悬挂看似是两个问题其实可以用同一张事务控制表解决关键是把事务的每个阶段状态都记下来。我一般会设计成这样的结构CREATE TABLE tcc_transaction ( tx_id VARCHAR(64) PRIMARY KEY, -- 全局事务ID branch_id VARCHAR(64) NOT NULL, -- 分支事务ID status TINYINT NOT NULL, -- 1:TRY成功 2:CONFIRM成功 3:CANCEL成功 4:已回滚(防悬挂) create_time DATETIME NOT NULL, update_time DATETIME NOT NULL, UNIQUE KEY uk_branch (branch_id) );Try 进来先按 branch_id 查有记录且状态是已回滚说明 Cancel 先到直接拒绝防悬挂没记录插入一条 TRY 成功记录并预留资源。Cancel 进来先查没记录插入一条已回滚记录并直接返回成功防空回滚同时这条记录还能挡住后续迟到的 Try有 TRY 记录执行资源释放并更新为 CANCEL 成功。这里有个细节值得说插入已回滚记录和判断是否已回滚必须是原子的否则并发下两个 Cancel 同时进来都判断没记录会重复插入。用 branch_id 做唯一索引靠数据库的唯一约束兜底是最省事的做法插入冲突就说明已经处理过了直接返回成功即可。注意状态表里的 branch_id 唯一约束是防并发的最后一道防线别省。我见过为了性能去掉唯一索引、改用先查后插的实现高并发下重复 Cancel 直接把冻结库存释放了两次账对不上查了半天。3. 幂等、重试与超时让 Confirm 和 Cancel 真正可靠TCC 的协调者本质上是个死磕到底的角色Try 成功了就一定要 Confirm 成功Try 失败了就一定要 Cancel 成功中间不管遇到什么异常都靠重试硬扛。这就要求 Confirm 和 Cancel 接口必须能承受反复调用也就是幂等。这块做不好重试越多错得越离谱。3.1 幂等不是加个唯一索引就完事很多人对幂等的理解停留在数据库加唯一索引重复插入报错就忽略。这在简单场景下够用但 TCC 的 Confirm/Cancel 幂等要考虑的更多。以 Confirm 为例它的语义是把冻结资源转为正式消耗。如果重复执行冻结库存会被减两次直接减成负数。所以 Confirm 必须先判断这笔事务的 Confirm 是不是已经做过了。判断依据还是那张状态表Confirm 进来先查状态如果已经是 CONFIRM 成功直接返回成功不做任何资源操作如果是 TRY 成功执行资源扣减并更新状态如果状态是 CANCEL 成功说明事务已经回滚了这时候再来 Confirm 属于异常应该拒绝并告警。Cancel 同理已经是 CANCEL 成功就直接返回是 TRY 成功就释放资源并更新是 CONFIRM 成功则拒绝。这里的状态判断和资源操作必须在同一个本地事务里完成否则判断完还没更新状态就挂了下次重试又会重复操作。用本地事务包住查状态—改资源—改状态三步是保证幂等的基本功。3.2 重试策略别用固定间隔死磕Confirm 和 Cancel 的重试不是简单加个 for 循环就行。固定间隔重试在服务短暂抖动时可能连续失败等抖动过去重试次数已经耗尽了而间隔太长又会让事务长时间处于中间态资源一直被占着。我一般用指数退避加最大次数限制第一次失败等 1 秒第二次 2 秒第三次 4 秒依次翻倍封顶到比如 5 分钟一次总重试次数设个上限比如 15 次覆盖大约几小时。超过上限还没成功就把这笔事务标记为待人工介入落一条告警让运维或开发去查。千万别无限重试否则一个坏掉的分支会拖垮整个协调者的线程池。重试还有个坑重试的请求必须带同样的全局事务 ID 和分支 ID不能每次重试生成新 ID否则参与方那边根本认不出这是同一笔事务幂等判断全失效。协调者要把事务上下文持久化下来重启后还能接着重试这也是为什么协调者自己也需要一张事务表。3.3 超时时间怎么定才不坑自己Try 的超时时间设置是个技术活。设太短正常慢请求被误判失败触发不必要的 Cancel白白浪费资源预留设太长真出问题时协调者要等很久才发现事务中间态持续时间过长冻结资源迟迟不释放。我的经验是Try 超时 参与方 Try 接口 P99 耗时 × 2 到 3 倍。比如库存服务 Try 的 P99 是 50ms那超时设 150ms 左右比较合理既给了正常波动空间又不会等太久。同时参与方内部也要设自己的超时比如 Try 里查库存、更新冻结库存这些操作各自设超时避免单个慢查询把整个 Try 拖死。Confirm 和 Cancel 的超时可以设得比 Try 长一些因为它们不涉及复杂的业务校验主要是资源操作但也不能无限长。另外协调者调用参与方的超时和参与方内部操作的超时要分层设置外层比内层大否则外层超时了内层还在跑容易产生协调者以为失败、参与方其实成功的错位。4. 从代码看 TCCTry、Confirm、Cancel 的落地写法光讲理论容易飘落到代码上才知道哪里会卡。下面用库存服务为例把三个接口的实现骨架和关键判断写出来重点看状态流转和幂等处理。4.1 Try 接口先查状态再预留Try 的核心是防悬挂 预留资源顺序不能乱。先查事务记录确认不是已回滚状态再执行预留。public boolean tryReserve(String txId, String branchId, Long skuId, int count) { // 1. 防悬挂先查是否已有回滚记录 TccRecord record tccMapper.selectByBranchId(branchId); if (record ! null record.getStatus() STATUS_ROLLBACKED) { // Cancel 先到了拒绝预留 return false; } if (record ! null record.getStatus() STATUS_TRY_SUCCESS) { // 重复 Try直接返回成功幂等 return true; } // 2. 本地事务插入 TRY 记录 冻结库存 return transactionTemplate.execute(status - { tccMapper.insertTryRecord(txId, branchId); int affected stockMapper.freezeStock(skuId, count); if (affected 0) { // 可用库存不足回滚本地事务 status.setRollbackOnly(); return false; } return true; }); }这里freezeStock的 SQL 要带条件类似UPDATE stock SET available available - #{count}, frozen frozen #{count} WHERE sku_id #{skuId} AND available #{count}靠available count这个条件保证不会超卖affected 为 0 就说明库存不够。把判断和更新放在一条 SQL 里避免先查后改的并发窗口。4.2 Confirm 接口状态机驱动拒绝非法流转Confirm 只认 TRY 成功这个前置状态其他状态一律按幂等或异常处理。public boolean confirm(String txId, String branchId, Long skuId, int count) { TccRecord record tccMapper.selectByBranchId(branchId); if (record null) { // 没有 Try 记录却来 Confirm属于异常告警 alertService.warn(confirm without try, branchId); return false; } if (record.getStatus() STATUS_CONFIRM_SUCCESS) { return true; // 幂等 } if (record.getStatus() ! STATUS_TRY_SUCCESS) { // 已回滚或其他状态拒绝 return false; } return transactionTemplate.execute(status - { // 冻结库存转出库冻结减少总库存实际减少 stockMapper.confirmStock(skuId, count); tccMapper.updateStatus(branchId, STATUS_CONFIRM_SUCCESS); return true; }); }confirmStock的 SQL 是UPDATE stock SET frozen frozen - #{count} WHERE sku_id #{skuId} AND frozen #{count}同样带条件防止冻结被减成负数。状态更新和资源操作在同一个本地事务里保证要么都成功要么都失败。4.3 Cancel 接口空回滚判断是第一步Cancel 要先处理没 Try 记录的情况这是防空回滚的关键。public boolean cancel(String txId, String branchId, Long skuId, int count) { TccRecord record tccMapper.selectByBranchId(branchId); if (record null) { // 空回滚Try 没成功插入回滚记录挡住后续迟到的 Try try { tccMapper.insertRollbackRecord(txId, branchId); } catch (DuplicateKeyException e) { // 并发下已被别的 Cancel 插入忽略 } return true; } if (record.getStatus() STATUS_CANCEL_SUCCESS) { return true; // 幂等 } if (record.getStatus() ! STATUS_TRY_SUCCESS) { return false; } return transactionTemplate.execute(status - { stockMapper.cancelStock(skuId, count); // 冻结转回可用 tccMapper.updateStatus(branchId, STATUS_CANCEL_SUCCESS); return true; }); }注意空回滚分支里插入回滚记录用了 try-catch 捕获唯一键冲突这是并发 Cancel 同时进来的兜底。cancelStock的 SQL 是UPDATE stock SET available available #{count}, frozen frozen - #{count} WHERE sku_id #{skuId} AND frozen #{count}冻结不足说明数据已经不一致了affected 为 0 要告警。4.4 三个接口的公共约束把上面三段代码的共同点拎出来其实是几条硬约束所有状态判断和资源操作必须在同一个本地事务里所有资源更新的 SQL 都要带条件available count或frozen count防止减成负数所有接口都要先查状态表再决定动作所有异常分支都要有告警别静默吞掉。这几条看着琐碎但少一条就可能在某个边界场景下把数据搞坏。5. 协调者视角全局事务怎么串起来参与方把三个接口实现好只是半件事另一半在协调者身上。协调者负责发起 Try、根据结果决定 Confirm 还是 Cancel、以及在这些动作失败时重试。它的可靠性直接决定整个 TCC 能不能跑稳。5.1 协调者的状态机设计协调者自己也要维护全局事务的状态一般有这几个TRYING正在执行 Try、CONFIRMING正在 Confirm、CANCELING正在 Cancel、FINISHED已完成。发起一笔事务时先落一条 TRYING 记录然后依次调用各参与方的 Try全部成功就转 CONFIRMING 并逐个 Confirm任一失败就转 CANCELING 并逐个 Cancel。这里的关键是协调者的状态变更也要持久化且和调用参与方的动作要有明确的先后。常见做法是先落状态再调用比如决定要 Cancel 了先把全局状态改成 CANCELING 落库再去调各参与方的 Cancel。这样即使协调者中途挂了重启后扫到 CANCELING 状态的事务能接着把没 Cancel 完的分支补上。如果反过来先调用再落状态挂了之后根本不知道这笔事务进行到哪了。5.2 分支事务的补偿顺序一笔全局事务有多个分支时Cancel 的顺序其实有讲究。理论上 TCC 的 Cancel 是各自独立的顺序不影响正确性因为每个分支只释放自己的预留资源。但工程上我倾向于按 Try 的逆序 Cancel原因是业务上往往有依赖关系——比如先扣库存再扣余额Cancel 时先还余额再还库存更符合业务直觉出问题时排查也顺。Confirm 的顺序则没那么讲究因为 Confirm 是确认消耗各分支互不影响并行调用都行。不过并行 Confirm 要注意控制并发度别一下子把下游打满我一般用个小线程池限制同时 Confirm 的分支数。5.3 协调者高可用不能只靠单机协调者如果是单点它挂了整个 TCC 就停摆。生产上协调者一般要做成集群但集群带来一个新问题同一笔事务不能被两个协调者同时处理否则重复 Confirm/Cancel。解决办法是给全局事务加锁比如用数据库的行锁或者分布式锁处理某笔事务前先抢锁抢到才处理。另一个思路是把协调者的重试逻辑做成扫描 认领模式后台线程定期扫状态表里处于中间态TRYING/CONFIRMING/CANCELING且超过一定时间没更新的事务认领后继续推进。认领用乐观锁带版本号更新保证只有一个线程能拿到。这种模式天然支持多实例部署挂了一个还有别的接着扫。6. TCC 的适用边界什么场景该用什么场景别硬上TCC 不是银弹它对业务的侵入性很强——每个参与方都要改造成三个接口还要维护状态表、处理幂等和异常。用错场景改造成本和维护负担会压垮团队。6.1 适合 TCC 的三类场景第一类是资金类业务比如支付、转账、账户扣款。这类业务对一致性要求极高且天然适合冻结—确认模型付款方先冻结金额收款方确认后再真正划转中间任何一步失败都能把冻结金额解冻资金不会凭空消失。银行和支付机构大量用这个模式不是没道理的。第二类是库存类业务尤其是秒杀、抢购这种高并发场景。Try 阶段冻结库存能有效防止超卖Confirm 阶段完成出库Cancel 阶段释放冻结。相比直接扣减再补偿冻结模型在并发下更稳。第三类是资源预订类比如机票座位、酒店房间、优惠券锁定。这类业务的共性是资源有限且需要临时占用和 TCC 的预留语义高度契合。6.2 不适合硬上 TCC 的情况如果业务本身对一致性要求没那么高比如发个通知、记个日志用 TCC 就是杀鸡用牛刀消息队列的最终一致性方案更轻量。如果参与方是第三方系统、你改不了它的接口那也没法做 TCC只能靠对账或者补偿任务兜底。还有一种情况要特别小心参与方的业务逻辑本身不支持预留语义。比如某个操作一旦执行就不可逆发了短信、调了外部接口你没法在 Try 阶段预留它这种就不适合 TCC。硬要套只能在 Try 阶段做校验、Confirm 阶段才真正执行但这样 Try 就没起到预留作用Confirm 失败时也没法补偿等于退化成两阶段提交的简化版可靠性打折扣。6.3 和 Saga、本地消息表的取舍TCC 常被拿来和 Saga、本地消息表比较。Saga 是长事务拆分每个步骤都有对应的补偿操作适合流程长、步骤多的业务但它的补偿是反向操作不像 TCC 有预留隔离中间态可能被其他请求看到。本地消息表靠消息队列保证最终一致实现简单但只保证最终中间可能长时间不一致且不适合强一致的资源扣减。我的取舍逻辑是需要强一致且资源可预留选 TCC流程长、步骤多、能接受最终一致选 Saga只是异步通知、对实时性要求不高选本地消息表。没有哪个方案通吃关键是看业务对一致性的真实要求和参与方的改造能力。7. 生产环境里那些文档不会写的细节理论讲完最后聊几个真正踩过才知道的坑。这些细节在方案文档里基本看不到但每一条都可能在某个深夜把你叫起来。7.1 冻结资源的对账不能省TCC 跑久了冻结池里难免有对不上的账——可能是某次 Cancel 没执行完、可能是人工误操作、也可能是代码 bug。所以一定要有对账机制定期把冻结库存和状态表里处于 TRY 成功但长时间未 Confirm/Cancel 的记录做比对发现异常就告警。对账的粒度我一般按天做全量、按小时做增量。全量对账扫所有冻结记录增量对账只看最近一小时状态有变化的。对不上的记录先别急着自动修复人工确认后再处理自动修复一旦逻辑有误可能把小问题放大成大事故。7.2 状态表的清理策略状态表会随着事务量增长越来越大的不清理迟早拖慢查询。但清理有讲究不能删还在中间态的记录否则重试时找不到状态幂等就失效了。我的做法是只清理处于终态CONFIRM 成功、CANCEL 成功、已回滚且超过一定时间比如 7 天的记录中间态的一律保留。清理用分批删除别一次性 delete 太多导致锁表。可以按 create_time 范围分批每批几千条删完 sleep 一下再删下一批。另外清理前最好先归档到历史表万一后面要查历史事务还有据可查。7.3 监控指标要盯住这几个TCC 的监控不能只看接口成功率有几个指标必须单独盯中间态事务的数量和持续时间TRYING/CONFIRMING/CANCELING 状态的事务如果持续增长说明有分支卡住了、Confirm/Cancel 的重试次数分布重试次数异常高说明下游不稳、空回滚和悬挂的触发次数这两个指标一旦非零就要查原因、冻结资源的增长趋势持续增长说明有资源没释放。这些指标我一般配成告警中间态事务超过阈值、空回滚次数突增、冻结资源超过总量的一定比例都直接推告警。别等用户投诉了才发现问题那时候数据可能已经错乱了。7.4 灰度上线和回滚预案TCC 改造涉及核心链路千万别一把梭全量上线。我的做法是先选一个非核心的、流量小的业务做试点跑一两周观察对账和监控都正常再逐步扩大范围。灰度期间要保留旧逻辑的开关出问题能快速切回去。回滚预案也要提前想好如果 TCC 上线后发现严重问题怎么回退已经产生的冻结资源怎么处理这些都要在上线前演练一遍。我见过没做回滚预案的团队上线出问题后手忙脚乱最后只能停服人工修数据代价极大。我个人在实际操作中的体会是TCC 的难点从来不在理论而在那些边角场景的工程处理——空回滚、悬挂、幂等、重试、对账每一个单独看都不复杂但组合起来就是一张需要仔细编织的网。把这张网织密了TCC 才能在生产环境里真正稳得住织不密它带来的麻烦可能比它解决的问题还多。所以每次决定用 TCC 之前我都会先问自己一句这个业务的参与方真的都能改造成支持预留语义吗想清楚这个问题再动手不迟。
