支付系统的分布式事务：两阶段提交与 TCC 的落地对比
支付系统的分布式事务：两阶段提交与 TCC 的落地对比
一、一笔支付，背后可能涉及三个服务、两个数据库和一个第三方
在电商支付链路中，一笔典型的支付操作涉及以下步骤：扣减用户账户余额、创建支付订单、调用第三方支付渠道、增加商家收款记录。这四个步骤发生在三个不同的服务里（账户服务、订单服务、支付网关），各自的数据库是独立的。
如果这四个步骤在一个单体数据库事务中，BEGIN→ 执行四个操作 →COMMIT，一致性由数据库保障。但在微服务架构下，这四个步骤跨了三个数据库，传统的事务语义失效了。扣减余额成功了，但创建订单失败了——用户的余额少了，商家也没收到钱。这就是分布式事务要解决的核心问题。
二、两阶段提交的机制与致命缺陷
两阶段提交（2PC）是分布式事务最经典的理论方案，但也是生产环境中最少直接使用的方案。
第一阶段（投票阶段）：协调者向所有参与者发送"准备提交"请求。每个参与者在本地执行事务逻辑（但不提交），然后返回"就绪"或"中止"。
第二阶段（提交阶段）：如果所有参与者都返回"就绪"，协调者发送"提交"请求，所有人正式提交。如果有一个参与者返回"中止"，协调者发送"回滚"请求。
2PC 的核心问题是同步阻塞。在第一阶段完成后，所有参与者都必须保持事务打开状态，等待协调者的第二阶段指令。如果协调者宕机了，参与者就会一直等待——锁资源（数据库行锁、连接等）全部被挂起的事务持有，其他请求无法访问这些数据。这就是所谓的"阻塞协议"的代价。
2PC 还有一个单点故障问题。协调者是整个协议的核心，如果它在第二阶段发送指令时宕机，部分参与者收到了提交请求，另一些没收到——数据就不一致了。
三、TCC 的补偿机制
TCC（Try-Confirm-Cancel）是 2PC 的一种工程化改良，引入了"补偿"的概念。
Try 阶段：预留资源。不真正执行扣减，而是冻结或预占。比如冻结账户余额（可用余额减少，冻结金额增加），创建状态为"待确认"的订单。
Confirm 阶段：所有参与者 Try 成功后，执行真正提交。把冻结金额转为实际扣款，把订单状态改为"已支付"。
Cancel 阶段：任一参与者 Try 失败后，所有参与者回退 Try 操作。解冻余额，取消订单。
TCC 相比 2PC 的核心改进是：Try 阶段不持有长时间锁。资源预留（如冻结余额）是一个状态变更，不需要数据库事务一直挂起等待。即使 Confirm 阶段的服务宕机了，也可以通过定时任务扫描"待确认"状态的记录，重新执行 Confirm。
/** * TCC 分布式事务的转账实现 * * 场景：从账户 A 转账 100 元到账户 B * * 为什么 TCC 比 2PC 更实用： * 1. Try 阶段不持有锁，只做"资源预留" * 2. Confirm/Cancel 都是幂等操作，可重试 * 3. 有明确的补偿路径（Cancel 回退 Try） */ public class TccTransferService { /** * Try 阶段：尝试预留资源 * * 原则：只预留，不真正扣减 */ public boolean tryTransfer(String fromAccount, String toAccount, int amount, String tccId) { // 冻结转出方余额 // INSERT INTO frozen_record(tcc_id, account, amount) VALUES(...) // UPDATE account SET available = available - amount WHERE ... // 约束：available >= 0（防止超额冻结） boolean frozen = accountService.freeze(fromAccount, amount, tccId); if (!frozen) { return false; // 余额不足，Try 失败 } // 创建待确认的转账记录 transferDao.insertPendingTransfer(tccId, fromAccount, toAccount, amount); return true; } /** * Confirm 阶段：确认提交 * * 原则：必须是幂等的（可能被重试多次） */ public void confirmTransfer(String tccId) { TransferRecord record = transferDao.getByTccId(tccId); if (record == null || "CONFIRMED".equals(record.getStatus())) { return; // 幂等：已确认的跳过 } // 解冻 → 真正扣款 accountService.confirmFreeze(record.getFromAccount(), record.getAmount(), tccId); // 增加收款方余额 accountService.credit(record.getToAccount(), record.getAmount()); // 更新记录状态 transferDao.updateStatus(tccId, "CONFIRMED"); } /** * Cancel 阶段：回滚 * * 原则：必须是幂等的，补偿 Try 阶段的所有操作 */ public void cancelTransfer(String tccId) { TransferRecord record = transferDao.getByTccId(tccId); if (record == null || "CANCELLED".equals(record.getStatus())) { return; // 幂等：已取消的跳过 } // 解冻余额 accountService.unfreeze(record.getFromAccount(), record.getAmount(), tccId); // 更新记录状态 transferDao.updateStatus(tccId, "CANCELLED"); } }四、TCC 的实践难点
TCC 理论上是优雅的，但实践中三个难点。
业务逻辑的侵入性：在单体应用的简单转账逻辑中，只有一行"余额 A 减 100，余额 B 加 100"。但在 TCC 模式下，需要把这个逻辑拆成 Try（冻结余额 A）、Confirm（真正扣 A 加 B）、Cancel（解冻 A）三个方法。代码量翻了 3 倍。
空回滚：Cancel 可能在 Try 之前被调用（比如 Try 请求超时，协调者以为失败了就调了 Cancel，但 Try 其实还没执行）。Cancel 方法需要能处理"没冻结但收到解冻请求"的情况。
幂等设计：Confirm 和 Cancel 都可能被重试。必须在数据库层面设计好幂等键（用 tcc_id 作为唯一约束），否则重复执行会出大问题。
五、总结
分布式事务没有银弹。2PC 理论完美但工程上难以落地（同步阻塞、单点故障）。TCC 是更实用的方案，用补偿机制替代了同步等待，每个阶段都是独立的、幂等的、可重试的操作。但 TCC 的侵入性很高——它要求业务模型在设计时就支持 Try-Confirm-Cancel 三段式。对于简单的场景，用本地消息表实现最终一致性可能比 TCC 更合适。技术方案没有绝对的优劣，只有和场景的匹配度。