一、问题现场还原那是一个双11大促的日子小王所在的电商公司系统架构是这样的用户下单 ↓ 订单服务 → 扣减库存 → 支付服务 → 发货 → 增加积分 ↓ ↓ ↓ ↓ ↓ 订单库 库存库 支付库 物流库 积分库问题场景用户支付成功后库存扣减了但积分增加失败了1. 订单服务订单创建成功 ✓ 2. 库存服务库存扣减成功 ✓ 3. 支付服务支付成功 ✓ 4. 积分服务积分增加失败 ✗ 5. 结果用户付了钱但没有得到积分要投诉小王一开始想用Transactional解决但很快就发现// ❌ 本地事务无法解决分布式事务问题 Transactional public void placeOrder(Order order) { orderService.createOrder(order); // 订单库 inventoryService.decreaseStock(); // 库存库另一个服务 paymentService.processPayment(); // 支付库另一个服务 pointService.increasePoints(); // 积分库另一个服务 }为什么不行每个服务调用不同的数据库Transactional只能保证单个数据库的ACID无法跨多个数据库保证一致性二、分布式事务的核心挑战2.1 CAP理论C (Consistency): 一致性——所有节点数据同时成功或失败 A (Availability): 可用性——系统一直可用 P (Partition Tolerance): 分区容错性——网络故障时系统仍能运行 分布式系统中P是必须的所以只能选择CP或AP - CP保证一致性牺牲可用性如传统2PC - AP保证可用性牺牲一致性如消息最终一致性2.2 分布式事务分类类型一致性性能复杂度适用场景2PC/XA强一致性低中对一致性要求高的场景TCC最终一致性中高对性能有一定要求的场景Saga最终一致性高中业务流程较长的场景消息队列最终一致性高低允许延迟一致的场景三、解决方案一TCC模式3.1 TCC核心思想TCC Try尝试 Confirm确认 Cancel取消 Try阶段 - 资源检查和预留 - 锁定资源但不完成业务 Confirm阶段 - Try阶段成功后执行 - 完成实际业务操作 - 提交事务 Cancel阶段 - Try阶段成功后后续步骤失败 - 回滚Try阶段预留的资源 - 取消事务3.2 TCC实战案例场景用户下单扣减库存Service public class InventoryServiceTCC { /** * Try阶段预留库存 */ Transactional public void tryDecreaseStock(Long productId, Integer count) { // 1. 检查库存是否充足 Inventory inventory inventoryMapper.selectByProductId(productId); if (inventory.getAvailable() count) { throw new RuntimeException(库存不足); } // 2. 冻结库存不真正扣减 int frozen inventoryMapper.frozenStock(productId, count); if (frozen 0) { throw new RuntimeException(库存冻结失败); } // 3. 记录TCC事务日志 TccTransactionLog log new TccTransactionLog(); log.setTransactionId(UUID.randomUUID().toString()); log.setProductId(productId); log.setCount(count); log.setStatus(TRY); tccMapper.insert(log); } /** * Confirm阶段确认扣减库存 */ Transactional public void confirmDecreaseStock(String transactionId) { // 1. 获取事务日志 TccTransactionLog log tccMapper.selectByTransactionId(transactionId); if (log null || !TRY.equals(log.getStatus())) { throw new RuntimeException(事务状态异常); } // 2. 真正扣减库存 inventoryMapper.decreaseFrozenStock(log.getProductId(), log.getCount()); // 3. 更新事务日志 log.setStatus(CONFIRM); tccMapper.updateStatus(log); } /** * Cancel阶段取消扣减库存 */ Transactional public void cancelDecreaseStock(String transactionId) { // 1. 获取事务日志 TccTransactionLog log tccMapper.selectByTransactionId(transactionId); if (log null) { return; // 幂等性没有Try记录直接返回 } if (!TRY.equals(log.getStatus())) { return; // 幂等性已经确认或取消过直接返回 } // 2. 释放冻结库存 inventoryMapper.releaseFrozenStock(log.getProductId(), log.getCount()); // 3. 更新事务日志 log.setStatus(CANCEL); tccMapper.updateStatus(log); } }3.3 TCC优缺点优点 ✅ 强一致性最终一致性 ✅ 性能优于2PC ✅ 适合高并发场景 缺点 ❌ 代码侵入性强每个业务都要写三个方法 ❌ 开发成本高 ❌ 需要处理幂等性、空回滚、悬挂等异常情况四、解决方案二Saga模式4.1 Saga核心思想Saga 将长事务拆分为多个本地事务 每个本地事务都有对应的补偿操作 正常流程 T1 → T2 → T3 → T4 → T5 全部成功 ✓ 异常流程 T1 → T2 → T3 → T4 ✗ 执行补偿 C3 ← C2 ← C1 回滚4.2 Saga实战案例场景订单处理流程/** * 订单Saga编排 */ Service public class OrderSagaService { Autowired private OrderService orderService; Autowired private InventoryService inventoryService; Autowired private PaymentService paymentService; Autowired private PointService pointService; /** * 正向流程执行所有步骤 */ Transactional public void executeSaga(Order order) { String sagaId UUID.randomUUID().toString(); try { // 步骤1创建订单 SagaStep step1 createOrder(order, sagaId); // 步骤2扣减库存 SagaStep step2 decreaseInventory(order, sagaId); // 步骤3处理支付 SagaStep step3 processPayment(order, sagaId); // 步骤4增加积分 SagaStep step4 increasePoints(order, sagaId); // 更新Saga状态为成功 updateSagaStatus(sagaId, COMPLETED); } catch (Exception e) { // 执行补偿流程 compensateSaga(sagaId, e); throw new RuntimeException(订单处理失败, e); } } /** * 补偿流程反向执行补偿操作 */ Transactional public void compensateSaga(String sagaId, Exception e) { log.error(Saga执行失败开始补偿sagaId{}, sagaId); // 获取所有已完成的步骤 ListSagaStep completedSteps sagaStepMapper.selectCompletedSteps(sagaId); // 按执行顺序反向补偿 Collections.reverse(completedSteps); for (SagaStep step : completedSteps) { try { switch (step.getStepName()) { case createOrder: orderService.cancelOrder(step.getBusinessId()); break; case decreaseInventory: inventoryService.restoreInventory(step.getBusinessId()); break; case processPayment: paymentService.refund(step.getBusinessId()); break; case increasePoints: pointService.decreasePoints(step.getBusinessId()); break; } // 更新步骤状态为已补偿 step.setStatus(COMPENSATED); sagaStepMapper.updateStatus(step); } catch (Exception ex) { log.error(补偿失败step{}, step, ex); // 补偿失败需要人工介入 alertService.sendAlert(Saga补偿失败 step.getStepName()); } } // 更新Saga状态为已补偿 updateSagaStatus(sagaId, COMPENSATED); } private SagaStep createOrder(Order order, String sagaId) { orderService.createOrder(order); SagaStep step new SagaStep(); step.setSagaId(sagaId); step.setStepName(createOrder); step.setBusinessId(order.getId()); step.setStatus(COMPLETED); sagaStepMapper.insert(step); return step; } private SagaStep decreaseInventory(Order order, String sagaId) { inventoryService.decreaseInventory(order.getProductId(), order.getQuantity()); SagaStep step new SagaStep(); step.setSagaId(sagaId); step.setStepName(decreaseInventory); step.setBusinessId(order.getId()); step.setStatus(COMPLETED); sagaStepMapper.insert(step); return step; } // ... 其他步骤类似 }4.3 Saga优缺点优点 ✅ 性能高不需要等待所有参与者 ✅ 适合长事务场景 ✅ 代码侵入性相对较小 缺点 ❌ 最终一致性不是强一致性 ❌ 补偿逻辑复杂 ❌ 无法保证原子性可能出现部分成功部分失败五、解决方案三消息队列推荐5.1 消息队列核心思想基于可靠消息的最终一致性 流程 1. 本地事务执行 发送消息原子性 2. 消息队列保证消息不丢失 3. 消费者重试机制 4. 死信队列处理失败消息5.2 RocketMQ事务消息实战/** * 基于RocketMQ事务消息的分布式事务 */ Service public class OrderTransactionMQService { Autowired private RocketMQTemplate rocketMQTemplate; Autowired private OrderMapper orderMapper; /** * 发送事务消息 */ public void placeOrderWithTransaction(Order order) { // 构建消息 MessageOrder message MessageBuilder.withPayload(order).build(); // 发送事务消息 // 参数1Topic // 参数2消息内容 // 参数3事务监听器 rocketMQTemplate.sendMessageInTransaction( order-topic, message, new OrderTransactionListener() ); } } /** * 事务消息监听器 */ RocketMQTransactionListener public class OrderTransactionListener implements RocketMQLocalTransactionListener { Autowired private OrderMapper orderMapper; Autowired private InventoryService inventoryService; /** * 执行本地事务 */ Override Transactional public RocketMQLocalTransactionState executeLocalTransaction(Message msg, Object arg) { try { Order order (Order) msg.getPayload(); // 1. 创建订单本地事务 orderMapper.insert(order); // 2. 扣减库存远程调用 inventoryService.decreaseInventory(order.getProductId(), order.getQuantity()); // 本地事务成功返回COMMIT消息会被消费 return RocketMQLocalTransactionState.COMMIT; } catch (Exception e) { log.error(本地事务执行失败, e); // 本地事务失败返回ROLLBACK消息会被删除 return RocketMQLocalTransactionState.ROLLBACK; } } /** * 检查本地事务状态 * (MQ如果长时间没收到回执会调用这个方法检查) */ Override public RocketMQLocalTransactionState checkLocalTransaction(Message msg) { Order order (Order) msg.getPayload(); // 检查订单是否存在 Order existingOrder orderMapper.selectById(order.getId()); if (existingOrder ! null) { // 订单已创建返回COMMIT消息会被消费 return RocketMQLocalTransactionState.COMMIT; } else { // 订单未创建返回ROLLBACK消息会被删除 return RocketMQLocalTransactionState.ROLLBACK; } } } /** * 消息消费者异步处理积分 */ RocketMQMessageListener(topic order-topic, consumerGroup point-consumer) public class OrderPointConsumer implements RocketMQListenerOrder { Autowired private PointService pointService; Override public void onMessage(Order order) { try { // 增加积分 pointService.increasePoints(order.getUserId(), order.getAmount()); } catch (Exception e) { log.error(增加积分失败, e); // 抛出异常MQ会自动重试 throw e; } } }5.3 消息队列优缺点优点 ✅ 性能高异步处理 ✅ 容错性强消息重试、死信队列 ✅ 代码侵入性小 ✅ 最终一致性 缺点 ❌ 最终一致性不是强一致性 ❌ 依赖消息队列可靠性 ❌ 消息延迟六、三种方案对比维度TCCSaga消息队列一致性强最终最终性能中高高复杂度高中低代码侵入强中弱适用场景对一致性要求高长事务允许延迟一致七、选型建议选择TCC ✅ 对一致性要求高如金融交易 ✅ 涉及金额较大的场景 ✅ 开发团队技术能力强 选择Saga ✅ 业务流程较长如审批流程 ✅ 可以接受最终一致性 ✅ 需要快速交付 选择消息队列 ✅ 对延迟不敏感如积分、通知 ✅ 高并发场景 ✅ 团队技术能力一般八、总结今天我们学到了要点说明分布式事务问题跨多个数据库的数据一致性TCC模式Try-Confirm-Cancel强一致性Saga模式正向执行反向补偿最终一致性消息队列异步处理重试机制最终一致性选型建议根据一致性要求、性能、复杂度选择今日互动你的项目中遇到过分布式事务问题吗是用什么方案解决的