周传炽跨行转账如何保证数据一致性？这个标题的杀伤力在于，很多人以为“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语义。