1. 分布式事务的本质与挑战在单体应用时代事务管理相对简单一个本地数据库连接就能保证ACID特性。但随着微服务架构的普及一个业务操作往往需要跨多个服务、多个数据源完成这就引出了分布式事务的核心问题——如何保证跨网络、跨数据库的操作要么全部成功要么全部回滚我经历过一个典型的电商场景用户下单时需要同时扣减库存、生成订单、增加积分。这三个操作分别由库存服务、订单服务和积分服务处理各自使用独立的数据库。当库存扣减成功但积分增加失败时如果没有分布式事务机制就会出现数据不一致的情况。分布式事务的难点主要体现在三个方面网络不可靠服务间通信可能失败或超时节点故障参与事务的任意服务都可能宕机性能损耗协调多个服务必然带来额外开销2. 主流分布式事务方案对比2.1 两阶段提交2PC2PC是最经典的分布式事务协议包含准备阶段和提交阶段。以订单创建为例协调者询问所有参与者订单服务、库存服务等能否提交参与者锁定资源并回复可以或拒绝协调者根据响应决定全局提交或回滚实际项目中建议使用成熟的2PC实现如Atomikos而不是自己造轮子。我在金融项目中用Atomikos处理跨行转账需特别注意事务超时设置通常30秒。2.2 TCC模式TCCTry-Confirm-Cancel要求每个服务实现三个接口Try预留资源如冻结库存Confirm确认使用预留资源Cancel取消预留某物流系统使用TCC处理运单创建// Try阶段 inventoryService.freeze(stockRequest); warehouseService.reserveSpace(spaceRequest); // Confirm阶段所有Try成功后才执行 orderService.confirmOrder(); inventoryService.reduceStock();TCC的优点是性能较好缺点是业务侵入性强。我在实践中发现设计良好的补偿机制是关键比如要给Cancel操作实现幂等性。2.3 Saga模式Saga通过本地事务补偿事务实现最终一致性。每个服务完成自己的本地事务后发布事件触发下一个服务。如果某步骤失败则执行已成功步骤的补偿操作。一个跨境支付案例国内账户扣款本地事务外汇兑换服务执行失败则触发步骤1的补偿境外账户入账Saga适合长周期业务流但要注意补偿可能失败的情况。我通常会设计一个后台任务定期检查未完成的Saga。2.4 本地消息表这是最简单的最终一致性方案核心思路是业务操作和消息写入本地数据库同一事务定时任务扫描未发送消息消费者处理消息并确认我在会员积分系统中采用此方案关键点是消息表要设计去重机制如业务ID类型唯一索引避免重复消费。3. 技术选型实战建议3.1 Seata框架解析Seata是目前最流行的分布式事务框架支持AT、TCC、Saga等模式。其AT模式的工作原理拦截SQL解析业务数据前后镜像生成undo_log记录回滚数据全局事务提交时异步删除undo_log需要回滚时用undo_log恢复数据部署Seata时要注意事务分组tx-service-group必须与应用匹配存储模式推荐用db文件模式不适合生产注册中心建议用Nacos而非默认的file3.2 Spring Cloud集成在Spring Boot项目中集成Seata的典型配置seata: enabled: true application-id: order-service tx-service-group: my_test_tx_group service: vgroup-mapping: my_test_tx_group: default config: type: nacos nacos: server-addr: 127.0.0.1:8848 registry: type: nacos我曾踩过一个坑如果使用Feign调用必须确保GlobalTransactional注解在调用方且超时时间大于Feign超时。3.3 性能优化技巧在高并发场景下分布式事务容易成为瓶颈。几个实测有效的优化手段减少事务参与者数量如非核心链路可异步处理Saga模式下设置合理的并行度对非关键业务采用最终一致性适当调整锁超时时间如Seata的lock.retryInterval某秒杀系统经过优化后TPS从200提升到1500关键是把库存扣减和订单创建拆分成两个阶段。4. 典型业务场景解决方案4.1 电商下单流程推荐组合方案库存预扣TCC模式Try阶段冻结库存订单创建本地事务积分发放本地消息表异步处理物流创建Saga模式这样既保证了库存不会超卖强一致性又避免了积分服务影响主流程最终一致性。4.2 金融转账场景银行场景通常需要强一致性建议跨行转账用XA协议各银行系统通常支持行内转账用Seata AT模式对账系统用TCC保证最终一致特别注意金额字段要用Decimal类型且Seata配置中需要增加金额字段的undo_log序列化。4.3 库存与订单协同经典问题是如何防止超卖。我的实践方案创建订单前先执行库存预扣SELECT...FOR UPDATE订单服务与库存服务部署同机房减少延迟设置库存预警阈值低于阈值走单独处理流程遇到过Redis库存缓存与数据库不一致的情况最终通过定期同步双重检查解决。5. 避坑指南与经验总结5.1 常见故障排查事务不生效检查清单数据源是否被Seata代理GlobalTransactional是否在入口方法异常是否被错误捕获需抛出RuntimeException空回滚问题出现原因Try未执行但收到Cancel解决方案增加事务状态记录表幂等控制所有Confirm/Cancel操作必须实现幂等建议使用业务唯一键状态机控制5.2 监控与运维生产环境必须配置Seata Server监控事务数、成功率等各服务的undo_log表大小监控分布式事务链路追踪结合SkyWalking我曾遇到undo_log表暴涨导致数据库挂掉的情况现在会定期清理已完成的事务日志。5.3 架构设计原则经过多个项目实践我总结出几条经验能不用分布式事务就不用优先考虑业务拆分强一致性和最终一致性要明确区分补偿机制设计比主流程更重要始终为分布式事务设置合理的超时时间在最近的一个物联网项目中我们最终采用本地事务消息队列定时对账的组合方案既保证了可靠性又避免了分布式事务的性能损耗。