支付系统的分布式事务两阶段提交与 TCC 的落地对比一、一笔支付背后可能涉及三个服务、两个数据库和一个第三方在电商支付链路中一笔典型的支付操作涉及以下步骤扣减用户账户余额、创建支付订单、调用第三方支付渠道、增加商家收款记录。这四个步骤发生在三个不同的服务里账户服务、订单服务、支付网关各自的数据库是独立的。如果这四个步骤在一个单体数据库事务中BEGIN→ 执行四个操作 →COMMIT一致性由数据库保障。但在微服务架构下这四个步骤跨了三个数据库传统的事务语义失效了。扣减余额成功了但创建订单失败了——用户的余额少了商家也没收到钱。这就是分布式事务要解决的核心问题。二、两阶段提交的机制与致命缺陷两阶段提交2PC是分布式事务最经典的理论方案但也是生产环境中最少直接使用的方案。第一阶段投票阶段协调者向所有参与者发送准备提交请求。每个参与者在本地执行事务逻辑但不提交然后返回就绪或中止。第二阶段提交阶段如果所有参与者都返回就绪协调者发送提交请求所有人正式提交。如果有一个参与者返回中止协调者发送回滚请求。2PC 的核心问题是同步阻塞。在第一阶段完成后所有参与者都必须保持事务打开状态等待协调者的第二阶段指令。如果协调者宕机了参与者就会一直等待——锁资源数据库行锁、连接等全部被挂起的事务持有其他请求无法访问这些数据。这就是所谓的阻塞协议的代价。2PC 还有一个单点故障问题。协调者是整个协议的核心如果它在第二阶段发送指令时宕机部分参与者收到了提交请求另一些没收到——数据就不一致了。三、TCC 的补偿机制TCCTry-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 更合适。技术方案没有绝对的优劣只有和场景的匹配度。
支付系统的分布式事务两阶段提交与 TCC 的落地对比一、一笔支付背后可能涉及三个服务、两个数据库和一个第三方在电商支付链路中一笔典型的支付操作涉及以下步骤扣减用户账户余额、创建支付订单、调用第三方支付渠道、增加商家收款记录。这四个步骤发生在三个不同的服务里账户服务、订单服务、支付网关各自的数据库是独立的。如果这四个步骤在一个单体数据库事务中BEGIN→ 执行四个操作 →COMMIT一致性由数据库保障。但在微服务架构下这四个步骤跨了三个数据库传统的事务语义失效了。扣减余额成功了但创建订单失败了——用户的余额少了商家也没收到钱。这就是分布式事务要解决的核心问题。二、两阶段提交的机制与致命缺陷两阶段提交2PC是分布式事务最经典的理论方案但也是生产环境中最少直接使用的方案。第一阶段投票阶段协调者向所有参与者发送准备提交请求。每个参与者在本地执行事务逻辑但不提交然后返回就绪或中止。第二阶段提交阶段如果所有参与者都返回就绪协调者发送提交请求所有人正式提交。如果有一个参与者返回中止协调者发送回滚请求。2PC 的核心问题是同步阻塞。在第一阶段完成后所有参与者都必须保持事务打开状态等待协调者的第二阶段指令。如果协调者宕机了参与者就会一直等待——锁资源数据库行锁、连接等全部被挂起的事务持有其他请求无法访问这些数据。这就是所谓的阻塞协议的代价。2PC 还有一个单点故障问题。协调者是整个协议的核心如果它在第二阶段发送指令时宕机部分参与者收到了提交请求另一些没收到——数据就不一致了。三、TCC 的补偿机制TCCTry-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 更合适。技术方案没有绝对的优劣只有和场景的匹配度。
