## 1. 项目概述 第一次接触分布式事务时我被这个看似简单实则复杂的领域深深吸引。作为从单体架构转型微服务的必经之路分布式事务问题就像悬在架构师头顶的达摩克利斯之剑。在电商系统中用户支付成功后需要同时更新订单状态、扣减库存、增加积分——这三个操作可能分布在不同的服务和数据库中如何保证它们要么全部成功要么全部回滚这就是典型的分布式事务场景。 Seata作为阿里开源的分布式事务解决方案提供了AT、TCC、Saga、XA四种模式。其中TCC模式因其灵活性和高性能特别适合对一致性要求严格的金融级场景。最近在重构公司支付系统时我选择用Seata的TCC模式解决了跨行转账的事务难题下面就把实战经验完整分享给大家。 ## 2. TCC模式核心原理 ### 2.1 三阶段操作设计 TCCTry-Confirm-Cancel的本质是将一个完整的业务逻辑拆分为三个阶段 1. **Try**资源预留阶段。比如转账场景中先冻结转出账户的100元不实际扣款同时预占转入账户的额度。 2. **Confirm**确认执行阶段。如果所有参与方Try都成功则执行真实操作实际扣除转出账户100元解冻并增加转入账户100元。 3. **Cancel**取消回滚阶段。如果任一参与方Try失败则解除所有预留解冻转出账户释放转入账户预占额度。 这种设计类似航空公司的订票流程——先预定座位Try乘客付款后确认出票Confirm超时未支付则释放座位Cancel。 ### 2.2 Seata的协调机制 Seata作为事务协调者TC通过以下流程保证事务一致性 1. 事务发起方TM通过GlobalTransactional注解开启全局事务 2. 各参与服务RM注册分支事务到TC 3. 第一阶段所有Try操作执行成功TC记录事务日志 4. 第二阶段根据Try结果触发Confirm或Cancel 5. TC定时轮询处理超时或异常的事务 关键点Seata的TC服务需要独立部署建议生产环境使用集群模式避免单点故障。 ## 3. 代码实现详解 ### 3.1 定义TCC接口 以账户服务为例定义资金操作的TCC接口 java LocalTCC public interface AccountTccService { TwoPhaseBusinessAction( name accountTcc, commitMethod confirm, rollbackMethod cancel ) boolean tryDeduct( BusinessActionContextParameter(paramName userId) String userId, BusinessActionContextParameter(paramName amount) BigDecimal amount ); boolean confirm(BusinessActionContext context); boolean cancel(BusinessActionContext context); }TwoPhaseBusinessAction标注Try方法需指定commit和rollback方法名BusinessActionContextParameter标注需要传递到Confirm/Cancel的参数本地调用需加LocalTCC注解远程Dubbo服务则不需要3.2 实现业务逻辑Service public class AccountTccServiceImpl implements AccountTccService { Autowired private AccountMapper accountMapper; Override public boolean tryDeduct(String userId, BigDecimal amount) { // 检查账户状态 Account account accountMapper.selectForUpdate(userId); if(account.getStatus() ! AccountStatus.NORMAL) { throw new RuntimeException(账户状态异常); } // 检查余额是否充足 if(account.getBalance().compareTo(amount) 0) { throw new RuntimeException(余额不足); } // 冻结金额Try阶段 account.setFrozenAmount(account.getFrozenAmount().add(amount)); accountMapper.updateFrozenAmount(account); return true; } Override public boolean confirm(BusinessActionContext context) { // 获取Try阶段参数 String userId (String)context.getActionContext(userId); BigDecimal amount new BigDecimal(context.getActionContext(amount).toString()); // 实际扣款Confirm阶段 Account account accountMapper.selectForUpdate(userId); account.setBalance(account.getBalance().subtract(amount)); account.setFrozenAmount(account.getFrozenAmount().subtract(amount)); accountMapper.updateBalance(account); return true; } Override public boolean cancel(BusinessActionContext context) { // 解冻金额Cancel阶段 String userId (String)context.getActionContext(userId); BigDecimal amount new BigDecimal(context.getActionContext(amount).toString()); Account account accountMapper.selectForUpdate(userId); account.setFrozenAmount(account.getFrozenAmount().subtract(amount)); accountMapper.updateFrozenAmount(account); return true; } }3.3 发起全局事务Service public class TransferService { Autowired private AccountTccService accountTccService; GlobalTransactional(timeoutMills 60000) public void transfer(String fromUserId, String toUserId, BigDecimal amount) { // 转出账户Try if(!accountTccService.tryDeduct(fromUserId, amount)) { throw new RuntimeException(转出账户操作失败); } // 转入账户Try if(!accountTccService.tryAdd(toUserId, amount)) { throw new RuntimeException(转入账户操作失败); } // 如果走到这里两个Try都成功Seata会自动触发Confirm } }4. 生产环境注意事项4.1 幂等性设计网络抖动可能导致Confirm/Cancel重复调用必须保证三个方法的幂等性。建议方案在业务表中添加事务状态字段tcc_status每次操作前检查状态Try成功后将状态设为TRY_SUCCESSConfirm/Cancel执行后更新为CONFIRMED/CANCELLED重复调用时直接返回当前状态CREATE TABLE t_account ( id VARCHAR(32) PRIMARY KEY, balance DECIMAL(18,2) NOT NULL, frozen_amount DECIMAL(18,2) DEFAULT 0, tcc_status VARCHAR(20) DEFAULT NULL, INDEX idx_tcc_status (tcc_status) );4.2 空回滚处理当Try未执行时收到Cancel调用如Try阶段超时需要允许空回滚public boolean cancel(BusinessActionContext context) { // 检查Try是否执行过 String userId (String)context.getActionContext(userId); Account account accountMapper.selectById(userId); if(account.getTccStatus() null) { // 记录空回滚日志 log.warn(空回滚, xid:{}, context.getXid()); return true; } // 正常回滚逻辑... }4.3 悬挂问题预防Cancel比Try先到达的情况称为悬挂解决方案在Try阶段检查是否存在对应xid的回滚记录如果存在则拒绝执行Trypublic boolean tryDeduct(String userId, BigDecimal amount) { // 防悬挂检查 if(rollbackLogMapper.existsByXid(context.getXid())) { throw new RuntimeException(存在悬挂风险拒绝执行Try); } // 正常Try逻辑... }5. 性能优化实践5.1 异步Confirm优化对于非核心链路可以采用异步Confirm提升性能Try阶段同步执行并返回结果Confirm阶段通过消息队列异步执行需要额外补偿机制处理Confirm失败public boolean confirm(BusinessActionContext context) { // 发送MQ消息 mqProducer.sendConfirmMessage( new ConfirmMessage() .setXid(context.getXid()) .setUserId(context.getActionContext(userId)) ); return true; } // MQ消费者处理Confirm RabbitListener(queues tcc-confirm-queue) public void handleConfirm(ConfirmMessage message) { // 实际Confirm逻辑 }5.2 批量操作支持高频小金额场景如红包雨可采用批量TCC模式定义批量操作的TCC接口Try阶段预占总额度Confirm阶段实际处理每个子订单TwoPhaseBusinessAction(name batchTransfer) boolean tryBatchDeduct( BusinessActionContextParameter(paramName batchId) String batchId, BusinessActionContextParameter(paramName totalAmount) BigDecimal totalAmount ); // Confirm阶段根据batchId处理明细6. 监控与排查6.1 关键监控指标事务成功率成功事务数/总事务数平均耗时各阶段耗时分布异常类型空回滚、悬挂等特殊场景计数建议通过PrometheusGrafana搭建监控看板示例配置# seata指标暴露 management: endpoints: web: exposure: include: prometheus metrics: tags: application: ${spring.application.name}6.2 日志排查技巧通过全局事务IDxid追踪全链路grep a5eef66d-12d7-4bb8 */logs/*.log常见错误码TC-101分支事务注册失败TC-102全局会话不存在TC-203分支事务状态异常7. 与其他模式对比7.1 TCC vs AT模式特性TCC模式AT模式侵入性高需改业务代码低无侵入性能高无全局锁中存在全局锁竞争适用场景金融等高一致性要求普通业务场景复杂度高需处理异常情况低自动回滚7.2 选型建议强一致性需求选择TCC遗留系统改造考虑Saga简单业务场景使用AT模式传统数据库XA模式可能更合适在最近的项目中我们将核心支付链路改造成TCC模式后分布式事务成功率从99.2%提升到99.99%平均耗时从120ms降低到80ms。当然这也带来了更高的开发成本——每个业务操作都需要仔细设计Try/Confirm/Cancel逻辑。建议根据业务重要性分级实施核心链路用TCC保证可靠性边缘业务可采用AT模式快速实现。
## 1. 项目概述 第一次接触分布式事务时我被这个看似简单实则复杂的领域深深吸引。作为从单体架构转型微服务的必经之路分布式事务问题就像悬在架构师头顶的达摩克利斯之剑。在电商系统中用户支付成功后需要同时更新订单状态、扣减库存、增加积分——这三个操作可能分布在不同的服务和数据库中如何保证它们要么全部成功要么全部回滚这就是典型的分布式事务场景。 Seata作为阿里开源的分布式事务解决方案提供了AT、TCC、Saga、XA四种模式。其中TCC模式因其灵活性和高性能特别适合对一致性要求严格的金融级场景。最近在重构公司支付系统时我选择用Seata的TCC模式解决了跨行转账的事务难题下面就把实战经验完整分享给大家。 ## 2. TCC模式核心原理 ### 2.1 三阶段操作设计 TCCTry-Confirm-Cancel的本质是将一个完整的业务逻辑拆分为三个阶段 1. **Try**资源预留阶段。比如转账场景中先冻结转出账户的100元不实际扣款同时预占转入账户的额度。 2. **Confirm**确认执行阶段。如果所有参与方Try都成功则执行真实操作实际扣除转出账户100元解冻并增加转入账户100元。 3. **Cancel**取消回滚阶段。如果任一参与方Try失败则解除所有预留解冻转出账户释放转入账户预占额度。 这种设计类似航空公司的订票流程——先预定座位Try乘客付款后确认出票Confirm超时未支付则释放座位Cancel。 ### 2.2 Seata的协调机制 Seata作为事务协调者TC通过以下流程保证事务一致性 1. 事务发起方TM通过GlobalTransactional注解开启全局事务 2. 各参与服务RM注册分支事务到TC 3. 第一阶段所有Try操作执行成功TC记录事务日志 4. 第二阶段根据Try结果触发Confirm或Cancel 5. TC定时轮询处理超时或异常的事务 关键点Seata的TC服务需要独立部署建议生产环境使用集群模式避免单点故障。 ## 3. 代码实现详解 ### 3.1 定义TCC接口 以账户服务为例定义资金操作的TCC接口 java LocalTCC public interface AccountTccService { TwoPhaseBusinessAction( name accountTcc, commitMethod confirm, rollbackMethod cancel ) boolean tryDeduct( BusinessActionContextParameter(paramName userId) String userId, BusinessActionContextParameter(paramName amount) BigDecimal amount ); boolean confirm(BusinessActionContext context); boolean cancel(BusinessActionContext context); }TwoPhaseBusinessAction标注Try方法需指定commit和rollback方法名BusinessActionContextParameter标注需要传递到Confirm/Cancel的参数本地调用需加LocalTCC注解远程Dubbo服务则不需要3.2 实现业务逻辑Service public class AccountTccServiceImpl implements AccountTccService { Autowired private AccountMapper accountMapper; Override public boolean tryDeduct(String userId, BigDecimal amount) { // 检查账户状态 Account account accountMapper.selectForUpdate(userId); if(account.getStatus() ! AccountStatus.NORMAL) { throw new RuntimeException(账户状态异常); } // 检查余额是否充足 if(account.getBalance().compareTo(amount) 0) { throw new RuntimeException(余额不足); } // 冻结金额Try阶段 account.setFrozenAmount(account.getFrozenAmount().add(amount)); accountMapper.updateFrozenAmount(account); return true; } Override public boolean confirm(BusinessActionContext context) { // 获取Try阶段参数 String userId (String)context.getActionContext(userId); BigDecimal amount new BigDecimal(context.getActionContext(amount).toString()); // 实际扣款Confirm阶段 Account account accountMapper.selectForUpdate(userId); account.setBalance(account.getBalance().subtract(amount)); account.setFrozenAmount(account.getFrozenAmount().subtract(amount)); accountMapper.updateBalance(account); return true; } Override public boolean cancel(BusinessActionContext context) { // 解冻金额Cancel阶段 String userId (String)context.getActionContext(userId); BigDecimal amount new BigDecimal(context.getActionContext(amount).toString()); Account account accountMapper.selectForUpdate(userId); account.setFrozenAmount(account.getFrozenAmount().subtract(amount)); accountMapper.updateFrozenAmount(account); return true; } }3.3 发起全局事务Service public class TransferService { Autowired private AccountTccService accountTccService; GlobalTransactional(timeoutMills 60000) public void transfer(String fromUserId, String toUserId, BigDecimal amount) { // 转出账户Try if(!accountTccService.tryDeduct(fromUserId, amount)) { throw new RuntimeException(转出账户操作失败); } // 转入账户Try if(!accountTccService.tryAdd(toUserId, amount)) { throw new RuntimeException(转入账户操作失败); } // 如果走到这里两个Try都成功Seata会自动触发Confirm } }4. 生产环境注意事项4.1 幂等性设计网络抖动可能导致Confirm/Cancel重复调用必须保证三个方法的幂等性。建议方案在业务表中添加事务状态字段tcc_status每次操作前检查状态Try成功后将状态设为TRY_SUCCESSConfirm/Cancel执行后更新为CONFIRMED/CANCELLED重复调用时直接返回当前状态CREATE TABLE t_account ( id VARCHAR(32) PRIMARY KEY, balance DECIMAL(18,2) NOT NULL, frozen_amount DECIMAL(18,2) DEFAULT 0, tcc_status VARCHAR(20) DEFAULT NULL, INDEX idx_tcc_status (tcc_status) );4.2 空回滚处理当Try未执行时收到Cancel调用如Try阶段超时需要允许空回滚public boolean cancel(BusinessActionContext context) { // 检查Try是否执行过 String userId (String)context.getActionContext(userId); Account account accountMapper.selectById(userId); if(account.getTccStatus() null) { // 记录空回滚日志 log.warn(空回滚, xid:{}, context.getXid()); return true; } // 正常回滚逻辑... }4.3 悬挂问题预防Cancel比Try先到达的情况称为悬挂解决方案在Try阶段检查是否存在对应xid的回滚记录如果存在则拒绝执行Trypublic boolean tryDeduct(String userId, BigDecimal amount) { // 防悬挂检查 if(rollbackLogMapper.existsByXid(context.getXid())) { throw new RuntimeException(存在悬挂风险拒绝执行Try); } // 正常Try逻辑... }5. 性能优化实践5.1 异步Confirm优化对于非核心链路可以采用异步Confirm提升性能Try阶段同步执行并返回结果Confirm阶段通过消息队列异步执行需要额外补偿机制处理Confirm失败public boolean confirm(BusinessActionContext context) { // 发送MQ消息 mqProducer.sendConfirmMessage( new ConfirmMessage() .setXid(context.getXid()) .setUserId(context.getActionContext(userId)) ); return true; } // MQ消费者处理Confirm RabbitListener(queues tcc-confirm-queue) public void handleConfirm(ConfirmMessage message) { // 实际Confirm逻辑 }5.2 批量操作支持高频小金额场景如红包雨可采用批量TCC模式定义批量操作的TCC接口Try阶段预占总额度Confirm阶段实际处理每个子订单TwoPhaseBusinessAction(name batchTransfer) boolean tryBatchDeduct( BusinessActionContextParameter(paramName batchId) String batchId, BusinessActionContextParameter(paramName totalAmount) BigDecimal totalAmount ); // Confirm阶段根据batchId处理明细6. 监控与排查6.1 关键监控指标事务成功率成功事务数/总事务数平均耗时各阶段耗时分布异常类型空回滚、悬挂等特殊场景计数建议通过PrometheusGrafana搭建监控看板示例配置# seata指标暴露 management: endpoints: web: exposure: include: prometheus metrics: tags: application: ${spring.application.name}6.2 日志排查技巧通过全局事务IDxid追踪全链路grep a5eef66d-12d7-4bb8 */logs/*.log常见错误码TC-101分支事务注册失败TC-102全局会话不存在TC-203分支事务状态异常7. 与其他模式对比7.1 TCC vs AT模式特性TCC模式AT模式侵入性高需改业务代码低无侵入性能高无全局锁中存在全局锁竞争适用场景金融等高一致性要求普通业务场景复杂度高需处理异常情况低自动回滚7.2 选型建议强一致性需求选择TCC遗留系统改造考虑Saga简单业务场景使用AT模式传统数据库XA模式可能更合适在最近的项目中我们将核心支付链路改造成TCC模式后分布式事务成功率从99.2%提升到99.99%平均耗时从120ms降低到80ms。当然这也带来了更高的开发成本——每个业务操作都需要仔细设计Try/Confirm/Cancel逻辑。建议根据业务重要性分级实施核心链路用TCC保证可靠性边缘业务可采用AT模式快速实现。
