TCC分布式事务实战：跨行转账数据一致性如何保证？-代码聚汇网

TCC分布式事务实战：跨行转账数据一致性如何保证？

周传炽·2026-09-04·阅读 21 GEO检测（免费）

分布式事务TCC数据一致性

|难度：普通|阅读约 44 分钟

跨行转账如何保证数据一致性？这个标题的杀伤力在于，很多人以为“A账户减掉10000，B账户加上10000”就是全部了，可真把两个账户放到两家银行的独立数据库里，一个网络抖动、一次进程重启，账面上就可能平白无故消失一万块。我当年第一次在账务系统里看到“扣款成功但对方迟迟未到账”的工单，脑子里冒出来的也是同一句话：数据一致性到底怎么保证？后来把TCC分布式事务完整落地到转账链路上，才真正理解这类场景为什么难、为什么普遍、该在哪里下功夫。

这篇我不会只讲概念，会直接围绕跨行转账这条业务链路，把TCC的三个阶段拆开，把两个独立银行库的表结构和代码写出来，最后聊几个只有上了生产才会踩到的坑。如果你是后端开发、架构师，或者任何一个正在被分布式事务折磨的人，这篇应该能帮你少走不少弯路。

1. 为什么“跨行转账”四个字，在技术圈会变成一道难题

1.1 一个转账动作，散落在两套系统里

先把业务场景说清楚。用户在A银行发起一笔转账，要从账户A扣掉1万块，打到B银行账户B里。传统单体架构里，如果这两个账户在同一张表、同一个数据库里，那很简单：开事务，update账户A余额减1万，update账户B余额加1万，commit，完事。数据库的本地事务会保证这两条SQL要么都成功，要么都失败。

但跨行转账天然不是这个玩法。A银行和B银行是两个法人机构、两套账务系统、两套数据库集群，中间还可能隔着支付通道或清算网络。于是“扣A加B”这个操作被拆成了两个服务调用、两个本地事务，分别提交在A库和B库。

问题就出在这里：没有任何一个数据库能同时管住A库和B库。A库提交了扣款，B库成功加了钱，这是最好的结果；怕就怕A库提交成功，B库入账失败，或者B库网络超时但其实已经入账——这种“部分成功”的局面，才是分布式系统里数据一致性要解决的本质问题。

1.2 数据一致性到底难在哪：部分成功是最坏的结果

分布式系统一个默认前提是：网络不可靠，节点可能故障，调用可能超时。这个结论落实到账务场景里非常残酷。假设A库扣钱成功了，发消息给B库的过程中网络闪断，B库没收到，这笔转账在业务账面上就是只有扣款没有入账，客户的钱凭空消失了一个交易周期。

最让人头疼的是“超时”这个词。协调方调B库超时了，不代表B库真的没执行，可能只是响应报文在路上丢了。这时候重试可能导致B库重复入账，不重试又可能真的漏账。你永远要假设对方的状态是未知的，而这恰恰是分布式事务各种机制存在的理由。

1.3 先定一个调子：强一致与最终一致

讲TCC之前，必须明确一件事：TCC解决的是“最终一致性”，它没法做到单机数据库那种强一致。强一致要求任意时刻读到的数据都是最新的、无中间态；最终一致则是系统允许一段时间内存在中间态，比如A库已经扣了、B库还没加，但通过补偿和重试机制，保证一段时间后账目收敛到一致状态。

跨行转账这类业务，对一致性的要求极高，但并不意味着必须强一致，因为资金从扣款到入账哪怕有几十秒的中间态，对用户来说是可以接受的。关键是系统必须能自愈：要么自动重试补上入账，要么自动回滚把扣掉的钱退回去。TCC就是在这种思路下设计出来的一套业务侵入式方案。

提示：在账务系统里，即使有了分布式事务，银行仍然不会省掉每日对账。技术手段保证的是“尽力及时收敛”，对账是“最后兜底”。两者不是二选一，后面我会专门讲。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 分布式事务主流方案盘点：为什么这次选TCC

不用急着写代码，先看备选方案，否则很容易用错工具。目前工程上广泛讨论的分布式事务方案，大致有四类：2PC/XA、本地消息表/事务消息、SAGA、TCC。我用跨行转账这个场景逐个筛一遍。

2.1 2PC/XA：用数据库锁强撑的同步协议

2PC两阶段提交，思路是引入一个协调者，先让所有参与者完成“准备”，都准备好了再统一提交。XA是数据库层面的规范实现，靠数据库自带的事务管理器来协调。

优势是强一致，多个库要么全提交要么全回滚，不用业务写补偿。但问题也很明显：准备阶段要持有数据库资源锁直到所有分支返回，一旦某个分支慢或者数据库抖动，锁的持有时间会无限拉长，系统吞吐直接被打残。跨行转账涉及的A库B库通常还在不同网络分区，网络抖动概率不低，用XA只要一次抖动就可能拖垮整条链路的数据源连接池。而且很多银行核心库出于风险控制根本不开放XA协议。

2.2 本地消息表与事务消息：可靠异步，但不会立刻到达

这个模式的思路是：本地事务完成业务操作后，同时往消息表写入一条消息，二者在同一个本地事务里提交，然后异步任务把消息投递到MQ，消费方处理完后更新消息状态。它的核心优点是实现简单、可靠，适合“你只管扣款，后续异步入账”的场景。

问题在于时效。如果A库扣款成功后异步发送通知，B库什么时候入账取决于MQ的积压和消费速度，账务就会在不可控的时间里停留在“扣款成功未入账”的中间态。而且如果中间态持续太久，用户侧看到的是钱扣了但对方没收到，客服压力会很大。这类方案通常配合对账和消息回溯使用，但作为主链路的一致性手段过于被动。

2.3 SAGA：长事务的补偿艺术

SAGA把一个长事务拆成一串本地事务，每个本地事务提交后，如果后序事务失败，就反向执行补偿事务，比如“扣款”的补偿是“退款”，“入账”的补偿是“冲正”。每个步骤都是独立的正常业务操作，长期占用资源问题解决了。

但SAGA的补偿设计在账务场景有个不适配点：它更多面向“操作后知道失败才补偿”，两步之间同样有一段不可控的时间差。跨行转账主链路上，我们希望尽量在每个分支都拿到确定性结果后再往前走，而不是等最终补偿。SAGA更适合订单流、审批流这种允许长时间中间态且对实时收敛要求不高的长链路，放到转账场景里不是不行，但从体验角度不如TCC干脆。

2.4 TCC的定位：业务侵入换来更短的不可用窗口

TCC（Try-Confirm-Cancel）本质上是一种业务层的补偿事务方案。它把每个分布式操作拆成三个阶段：Try阶段做资源预留和检查，Confirm阶段真正提交，Cancel阶段回滚预留。协调者主导这三个阶段的调度，每个分支事务的完成都是确定性的局部结果，失败的分支能立刻被Cancel掉，整体上能在一个较短的时间窗口内收敛。

对比下来：

比2PC轻，不依赖数据库分布式事务协议，也不需要长时间持锁；
比异步消息更具实时性，Try和Confirm之间是同步的确定性调度，可以把中间态压缩到秒级；
比SAGA可靠，因为提前做了资源预留，Cancel能直接释放预留资源，不需要发一个“冲正事务”经过业务流再走一遍。

代价是业务代码侵入性确实强，每个分支都要自己实现三个接口，还要维护事务状态机。订单和库存扣减这类互金场景也大量采用TCC，就是因为它能兼顾确定性和实时性。跨行转账天然适配：扣款方需要先冻结资金，入账方需要校验后预留入账，正好对应TCC的Try语义。

3. TCC三阶段拆解：Try、Confirm、Cancel分别在做些什么

3.1 Try阶段：不是“直接扣款”，而是“先冻结”

很多人对TCC的第一个误解，是把Try当成“试一下”。实际上Try阶段不是试探性执行，它要做两件事：业务检查，以及资源预留。资源预留的意思是，用一个明确的账务状态把将来要扣的钱先锁住，但这个锁不能影响正常扣款流程以外的事务。

用转账场景解释。A银行账户A要向B银行账户B转账1万，TCC主事务启动后：

A账户服务执行Try：检查A账户余额是否足够、账户状态是否正常，如果检查通过，就把1万从可用余额划到冻结余额，对应一条SQL：update account_a set frozen_amount = frozen_amount + 10000, available_amount = available_amount - 10000 where account_id = 'A'。
B账户服务执行Try：检查B账户号是否有效、账户状态是否可入账，检查通过后并不真的入账，而是预留一个待入账标记或写入一条账务流水草稿，记录“这笔钱很快会到”。

Try阶段的关键是：这个阶段做的任何改动都要能回退。A账户的冻结可以解冻，B账户的预留可以被取消，这样后续Confirm失败或者Cancel触发时，事务能恢复原状。另一个关键点是，Try阶段的检查要尽可能穷尽所有可能失败的场景，因为Try把失败拦下来，Confirm阶段才敢保证大概率成功。

3.2 Confirm阶段：把预留变成事实

当所有分支的Try都返回成功，协调者进入Confirm阶段。Confirm阶段要把预留资源真正落地，每个参与者各自提交自己的本地事务，让它变成不可撤销的事实。

对应跨行转账：

A账户服务Confirm：把冻结资金变成实际扣款，即更新账户状态，把frozen_amount减掉1万，同时把扣款流水状态置为成功，标记该笔转账已经扣出。
B账户服务Confirm：把Try阶段预留的入账流水正式入账，给B账户余额增加1万，流水状态置为成功。

Confirm的设计核心是“不容忍失败”。不是说它真不会失败，而是所有可能导致失败的风险都应当提前在Try阶段排掉。Confirm内部就算遇到数据库抖动，也必须能通过重试补偿完成；协调者对Confirm的调用要一直重试到成功，不能轻率地让业务回滚。因为一旦某个分支的Try已经给用户展示了“资金已冻结”的可信结果，Confirm执行不下去，就会把账务暂停在冻结状态。

3.3 Cancel阶段：把账目退回原样

当任意一个分支的Try失败，或者协调者收到超时/异常信号，Cancel阶段就会对已经完成Try的分支做反向操作。

A账户服务Cancel：如果A的Try已经冻结了1万，Cancel就把冻结释放，即把frozen_amount减1万，available_amount加回1万。
B账户服务Cancel：如果B的Try已经写入待入账流水，Cancel就把该流水标记为取消，不产生任何真实余额变动。

Cancel同样要满足“可重复执行”和“幂等”，因为分布式环境下Cancel调用也可能因为网络超时而重发。Cancel本身也是业务状态的修改，和正常转账一样需要落库和记录状态，不能只放在内存里。

3.4 TCC与“补偿”“回滚”的本质差异

很多人会问：TCC和SAGA都做补偿，有什么区别？我个人的理解是，SAGA面向“正常提交后，回头取消”的场景，每一步都是完整业务动作；TCC则把每个动作预拆成“预留”和“落地”两个阶段，Cancel直接作用于预留资源。

这事放到数据库层就好理解了：数据库事务里的undo日志记录的是“数据变更前镜像”，TCC里的Try冻结记录的是“可回滚的业务化预留”。所以TCC的Cancel不是简单地执行一条相反SQL了事，它必须知道之前留过什么资源、哪笔流水是它预留的，才能精准释放。这也是为什么TCC一定要有事务上下文和分支流水记录，而不能靠拍脑袋写反向SQL。

4. 转账转账TCC实战：从建表到协调器一次打通

有了理论铺垫，现在进入实战。我假设一个简化的跨行转账系统：A服务属于A银行，管理账户A；B服务属于B银行，管理账户B；两者各自独立数据库，通过HTTP/OpenFeign通信；中间由一个事务协调器负责发起TCC流程。

4.1 场景设定：两个独立库，两个账户

先定义业务背景：

账户A：卡号 622200001，余额 50000，所在A库；
账户B：卡号 622200002，余额 10000，所在B库；
请求体：转出账户A 向转入账户B 转账 10000 元。

为了演示分布式事务，A库和B库互相不可见。A服务只负责A库的数据，B服务只负责B库的数据，协调器不落业务数据，只记录全局事务状态。

4.2 数据库表结构：把“冻结资金”显式建模

A库需要账户表和扣款冻结流水表。B库需要账户表和入账预留流水表。注意每张业务流水表必须带全局事务ID（tx_id），这是TCC幂等和追溯的根基。

A库的账户表设计：

sql复制create table account_a (
  account_id varchar(32) primary key,
  available_amount decimal(18,2) not null default 0.00,
  frozen_amount decimal(18,2) not null default 0.00,
  status varchar(8) not null default 'ACTIVE',
  version int not null default 0
);

A库的分支流水表：

sql复制create table account_a_tx_log (
  id bigint primary key auto_increment,
  tx_id varchar(64) not null,
  account_id varchar(32) not null,
  amount decimal(18,2) not null,
  action varchar(16) not null comment 'FREEZE / CONFIRM / CANCEL',
  status varchar(16) not null comment 'PENDING / SUCCESS / FAIL',
  create_time datetime default current_timestamp,
  unique key uk_tx_action (tx_id, action)
);

B库的账户表：

sql复制create table account_b (
  account_id varchar(32) primary key,
  balance decimal(18,2) not null default 0.00,
  status varchar(8) not null default 'ACTIVE'
);

B库的分支流水表：

sql复制create table account_b_tx_log (
  id bigint primary key auto_increment,
  tx_id varchar(64) not null,
  account_id varchar(32) not null,
  amount decimal(18,2) not null,
  action varchar(16) not null comment 'RESERVE / CONFIRM / CANCEL',
  status varchar(16) not null comment 'PENDING / SUCCESS / FAIL',
  create_time datetime default current_timestamp,
  unique key uk_tx_action (tx_id, action)
);

字段设计有几个讲究点：

账户余额表必须拆出可用余额和冻结余额，不拆的话Try和Confirm之间没法区分哪些钱已经被预留；
version 字段用来做乐观锁，防止并发转账下同一账户被多次Try冻结出超额资金；
流水表的 uk_tx_action (tx_id, action) 唯一键本身就是幂等屏障，同一个事务的同一个动作只能成功落一次，天然挡住网络重试产生的重复请求。

4.3 分支事务服务实现：Try/Confirm/Cancel接口落地

下面给出A服务三个接口的一个可参考写法。先看Try接口：

java复制@PostMapping("/tcc/try")
public Result try(@RequestBody TccRequest req) {
    String txId = req.getTxId();
    BigDecimal amount = req.getAmount();
    // 1. 幂等检查：同txId同action已有SUCCESS记录，直接返回成功
    if (hasSuccessLog(txId, "FREEZE")) {
        return Result.success();
    }
    // 2. 本地事务里，用乐观锁执行冻结
    int count = accountMapper.freeze(req.getAccountId(), amount);
    if (count == 0) {
        // 可用余额不足或账户被并发修改，返回失败让协调器触发Cancel
        return Result.fail("余额不足或状态异常");
    }
    // 3. 记录冻结流水
    txLogMapper.insert(txId, accountId, amount, "FREEZE", "SUCCESS");
    return Result.success();
}

对应SQL里的冻结操作：

sql复制update account_a
set available_amount = available_amount - #{amount},
    frozen_amount = frozen_amount + #{amount},
    version = version + 1
where account_id = #{accountId}
  and status = 'ACTIVE'
  and available_amount >= #{amount}
  and version = #{version};

这里有个小坑：try 接口中如果先插入流水再冻结，或者先冻结再插流水，一旦第二步失败就会留下脏数据。所以最稳的顺序是一个本地事务里同时执行冻结和插流水，任何一步失败整体回滚。上面的伪码拆开是便于阅读，工程里应该加 @Transactional 把它们放到同一个事务里。

Confirm接口，把冻结资金落成实际扣款：

java复制@PostMapping("/tcc/confirm")
public Result confirm(@RequestBody TccRequest req) {
    String txId = req.getTxId();
    // 幂等检查
    if (hasSuccessLog(txId, "CONFIRM")) {
        return Result.success();
    }
    // 本地事务：把冻结金额清零，完成扣款
    int count = accountMapper.confirmFreeze(req.getAccountId(), req.getAmount());
    if (count == 0) {
        // 说明Try阶段根本没冻结成功，Confirm应返回失败，交协调器处理
        return Result.fail("冻结记录不存在");
    }
    txLogMapper.insert(txId, accountId, amount, "CONFIRM", "SUCCESS");
    return Result.success();
}

Confirm阶段的冻结转扣款SQL：

sql复制update account_a
set frozen_amount = frozen_amount - #{amount},
    version = version + 1
where account_id = #{accountId}
  and frozen_amount >= #{amount};

Cancel接口，解冻资金、回滚流水状态：

java复制@PostMapping("/tcc/cancel")
public Result cancel(@RequestBody TccRequest req) {
    String txId = req.getTxId();
    if (hasSuccessLog(txId, "CANCEL")) {
        return Result.success();
    }
    // 释放冻结
    int count = accountMapper.unfreeze(req.getAccountId(), req.getAmount());
    txLogMapper.insert(txId, accountId, amount, "CANCEL", "SUCCESS");
    return Result.success();
}

解冻SQL：

sql复制update account_a
set available_amount = available_amount + #{amount},
    frozen_amount = frozen_amount - #{amount},
    version = version + 1
where account_id = #{accountId}
  and frozen_amount >= #{amount};

B服务也是类似套路，只是Try阶段不改变真实余额，只写入一条“待入账”的流水；Confirm阶段给B账户加钱并更新流水状态；Cancel阶段把流水标记取消。核心差异在于：A库的Try和Cancel是资金字段的显式变更，B库的Try和Cancel更多是流水级别的状态预留，直到Confirm才真正动到余额。这种不对称恰恰说明TCC的Try怎么设计，完全取决于业务分支要求哪种“预留语义”。

4.4 协调器：主宰状态迁移的回滚引擎

分支服务都就绪后，剩下最重要的一块是协调器。协调器负责调用各分支的Try，全部成功则依次调用Confirm，任何一个失败或超时就反向调用Cancel。它还需要持久化保存全局事务状态，防止协调器宕机后无法恢复。

全局事务表可以这样设计：

sql复制create table global_tx (
  tx_id varchar(64) primary key,
  status varchar(16) not null comment 'TRYING / CONFIRMING / CANCELLING / FINISHED',
  create_time datetime default current_timestamp,
  update_time datetime default current_timestamp on update current_timestamp
);

协调器的核心处理逻辑：

java复制public void executeTransfer(TransferRequest req) {
    String txId = genTxId();
    // 1. 写入TRYING状态
    globalTxMapper.insert(txId, "TRYING");

    // 2. 调起所有分支Try
    boolean tryOk = true;
    List<String> branchList = buildBranchList(req);
    for (String branch : branchList) {
        Result res = httpClient.invokeTry(branch, req, txId);
        if (!res.isSuccess()) {
            tryOk = false;
            break;
        }
    }

    // 3. Try全部成功，进入Confirm阶段；否则进入Cancel阶段
    if (tryOk) {
        globalTxMapper.updateStatus(txId, "CONFIRMING");
        try {
            for (String branch : branchList) {
                // 对Confirm失败做有限次重试，仍失败则记录并等待定时任务兜底
                httpClient.invokeConfirmWithRetry(branch, req, txId, 3);
            }
            globalTxMapper.updateStatus(txId, "FINISHED");
        } catch (Exception e) {
            // 协调器本身异常，事务停在CONFIRMING，由扫表任务接管
            notifyMonitor(txId, "confirm fail");
        }
    } else {
        globalTxMapper.updateStatus(txId, "CANCELLING");
        for (String branch : branchList) {
            if (hasTrySuccess(branch, txId)) {
                httpClient.invokeCancel(branch, req, txId);
            }
        }
        globalTxMapper.updateStatus(txId, "FINISHED");
    }
}

这段代码为了可读性已经做了大简化。工程上要考虑的点包括：

对每个分支的调用都需要超时控制，一般HTTP客户端设置2~3秒连接超时和3~5秒读取超时，多个分支可以并行调用缩短总耗时；
Confirm阶段要设计重试策略，前两次快速重试，后续退避时间拉长，但绝不能无界重试；
协调器必须支持多实例部署，同时用分布式锁或数据库行锁防止同一个txId被两个协调器实例重复调度。

4.5 打通一次完整转账：时序与调用关系

为了使调用关系更清楚，我用文字描述一次正常转账的完整时序，这比画图更扎实：

用户在A银行发起转账，转账服务创建主事务tx_id，落库TRANSFER_INIT；
协调器调用A账户服务的/tcc/try，A库在本地事务里检查账户状态和余额，冻结10000，记录FREEZE流水，返回成功；
协调器调用B账户服务的/tcc/try，B库校验账户号有效且状态正常，在入账流水表写一条RESERVE待入账记录，返回成功；
协调器确认所有Try成功，进入Confirm阶段，先调A的/tcc/confirm，A库把frozen_amount减少10000，标记扣款完成，返回成功；
协调器调B的/tcc/confirm，B库把10000加到balance，RESERVE流水状态更新为CONFIRM_SUCCESS，返回成功；
协调器把全局事务表状态更新为FINISHED，转账流程结束。

如果第3步B的Try失败，协调器会调A的/tcc/cancel，A库解冻10000，资金回到可用余额，整个流程走到CANCELLED终态。用户看到的结果是“转账失败，请重试”，A账户余额没有变化。

要注意步骤4和5之间存在一个时间差：A库已经扣款成功，B库还在Confirm中。这个中间态是完全正常的，因为协调器会继续推进B的Confirm直到成功。真正的危险是协调器在步骤4后宕机，后面我会在问题章节专门讨论。

5. 线上最容易踩的四个坑：空回滚、悬挂、幂等、超时

TCC代码跑通不是终点。我见过太多团队在Demo阶段看起来很顺畅，一压测、一模拟故障，各种状态错乱就冒出来了。下面这四类问题基本属于TCC落地必考题。

5.1 空回滚：Try都没执行成功，Cancel来了怎么办

场景是这样的：协调器调A服务的Try接口，网络超时了。协调器等不到响应，判定Try失败，直接进入Cancel阶段，开始调A服务的Cancel。但真实世界里，超时并不代表A服务没执行Try——可能A服务已经执行了冻结，只是响应报文丢了；也可能A服务压根没收到请求，什么都没发生。

如果Try没执行，Cancel直接去解冻一个不存在的冻结资金，就会解冻出负数或者报错，甚至把其他并发事务冻结的钱错误地释放了，这种问题在账务系统里是灾难级的。专业说法叫“空回滚”。

解决办法是在分支服务的流水表上做仲裁：Cancel到达时，先按tx_id查一下本地事务日志。如果这条tx_id的Try阶段压根没有成功记录，说明这是一次空回滚，Cancel直接返回成功并写入一条CANCEL_SKIP标记，不做任何资金变动；如果Try有成功记录，才真正执行释放冻结的操作。前面设计流水表时要求每笔Try必须落库，就是为了这个判断能成立。

5.2 悬挂：Cancel先到，Try后到

悬挂和空回滚是一对孪生问题。网络超时后协调器进入Cancel并成功调用了A的Cancel，但Cancel的响应还没回来时，之前超时的Try请求又因为某个重试机制到达了A服务，正常执行了资金冻结。

现在状态变成：协调器认为这个事务已经取消了，A服务却还冻着一笔钱没有人去解冻。这笔冻结资金会一直悬挂在那里，用户看到余额少了1万，实际转账又没成功，比空回滚还隐蔽。

解决思路是状态机前置检查。A服务在Try执行时必须先查流水表里是否存在同tx_id的CANCEL成功记录，存在说明协调器已经放弃这个事务，这个Try请求本身就是过期的，必须拒绝执行，或者只记录一笔TRY_BLOCKED后直接返回成功（但绝不修改资金）。只有确认没有CANCEL记录，Try才能继续冻结。用唯一键配合状态判断，才能把悬挂问题堵死。

5.3 Confirm/Cancel的幂等控制

分布式系统里，同一个请求被重复投递几乎无法避免。协调器的重试、客户端的超时重发、MQ的重复消息，都会导致A服务的Confirm被调用两次甚至更多。如果Confirm没有幂等保护，B账户就会被重复入账两次，账实不符。

我处理幂等的方式比较朴素：靠数据库唯一键兜底，而不是靠服务内存里的一个Set判断。每次Confirm/Cancel执行前先尝试插入一条流水记录，action加上唯一键约束，如果插入就报DuplicateKey说明这个动作已经执行过，直接返回成功。这里的关键点是“直接返回成功而非失败”，因为重复请求从业务语义上讲是预期的，不能当作异常失败去触发更上层补偿，否则会产生二次补偿。

5.4 冻结资源不释放与超时兜底

还有一个在账务系统里非常敏感的坑：如果协调器在Confirm阶段宕机，A库已经冻结的钱没有被解冻，也没有变成扣款，一直停在frozen_amount里。如果这种情况没有兜底，影响会积累成一个越来越大的资金池，最终账务不平。

这类问题光靠TCC协调器自身很难完全规避，必须配合对账巡检任务：定时扫描global_tx表里长时间停留在TRYING、CONFIRMING、CANCELLING中间态的事务，把事务ID捞出来后按分支状态查流水表，判断哪个分支还悬着，然后定向推进或者补偿。同时，如果冻结状态持续超过业务设定阈值（比如30分钟），账户层也要有自动解冻机制，防止单笔异常把用户全部资金锁死。

注意：在账务系统里“宁可重复补偿，也不要不补偿”，但补偿逻辑必须都是可追溯、可幂等的。所有自动补偿动作都要留审计日志，方便事后复盘。

6. 上线后别急着庆祝：对账巡检与兜底补偿

6.1 日切对账：账务系统的最后一道防线

跨行转账系统上线一段时间后你会明白，TCC再完备，也做不到百分之百规避所有异常并发。协调器代码bug、上线脚本失误、某个分支库出现未预期的数据倾斜，都可能造成漏单或者重复账。这种时候，靠的不是修补分布式事务逻辑，而是账务行业已经沉淀几十年的日切对账机制。

A库和B库每天夜间生成当日的所有交易流水和余额快照，通过对账系统按tx_id逐笔匹配，找出“A库已扣B库未入”“B库已入A库未扣”“两边都有但金额不一致”的差异记录。对账的意义在于，它把数据一致性从“运行时保证”升级为“离线可证伪”，一旦发现diff就能按账单定向修复。

转账服务的账务流水表在设计时必须预留对账用的关键字段：tx_id、双方账号、金额、状态、渠道流水号、记账时间。少了任何一项，对账脚本都很难写。这也是为什么我反复强调流水表不能省，那不是为了应付分布式事务，而是给对账铺路。

6.2 监控长事务与自助补偿工具

除了日终对账，运行时的监控也要盯紧。我给转账TCC链路配的指标大概有这几类：

全局事务的平均耗时和成功率；
每个分支Try/Confirm/Cancel的耗时P99；
处于中间态超过30秒、60秒、300秒的全局事务数量；
冻结资金总额与冻结订单数量，确认没有出现持续累积的冻结量；
Confirm调用重试次数分布，超过3次就要告警。

配套的是一套人工补偿工具。当系统监控发现某个事务卡在CONFIRMING超过阈值但自动重试始终失败，比如B库停机维护，操作人员可以通过后台工具查看global_tx状态和两个库的分支流水，确认B库确实没入账后，点击“重新Confirm”，系统会自动再调一次B服务的Confirm接口。整套工具不需要直接改数据库，所有操作都在业务接口层面完成，天然有幂等保护。

补充一个实操原则：能通过业务接口补偿的，绝对不要绕过业务层直接改数据库。直接UPDATE余额或者UPDATE流水状态看着最快，但很容易把已经写入的分支流水搞乱，造成跨库diff，最终对账会非常痛苦。

最后再说说我对TCC技术选型的真实体会。分布式事务没有完美的银弹，2PC太重，消息方案太慢，SAGA收敛得又不够及时。TCC确实要写不少代码，每个分支要维护自己的Try、Confirm、Cancel，还要处理空回滚、悬挂、幂等这些讨厌的边界问题，但它在业务控制力上是最强的——每个中间态都是可见的，每个失败点都是可补偿的，这对资金链尤其重要。如果让我重新做一个账户转入转出系统，我大概率还是会选TCC作为主干方案，再配一套扎实的对账和巡检系统做后盾，上线后心里才有底。