分布式事务实战：如何确保a函数调用b函数插表后的原子性回滚

1次阅读

共计 3154 个字符，预计需要花费 8 分钟才能阅读完成。

在微服务架构中，当服务 A 的函数 a 调用服务 B 的函数 b 完成数据库插入操作后，如果后续 a 函数执行出现异常，如何保证这两个操作的原子性回滚成为一个棘手的问题。传统单体应用中的数据库事务无法跨越服务边界，导致这种场景下的数据一致性难以保障。

常见的问题场景包括：

订单服务创建订单后调用库存服务扣减库存，扣减成功但订单创建失败
支付服务完成支付后调用会计服务记账，记账成功但支付回调处理失败
用户注册服务创建账号后调用权限服务分配角色，分配成功但注册信息保存失败

这些场景都会导致系统数据不一致，需要人工介入修复，严重影响系统可靠性。

通过在调用方服务本地建立事务记录表，利用本地事务保证业务操作和事务记录的原子性。

优点：

实现简单，不需要额外中间件
对现有代码侵入性小

缺点：

需要定时任务扫描和重试
事务状态管理复杂
不适合长事务场景

将一个分布式事务拆分为多个本地事务，每个本地事务都有对应的补偿操作。

优点：

支持长事务
无锁设计，性能较好

缺点：

补偿逻辑实现复杂
存在脏读问题
难以保证隔离性

Try-Confirm-Cancel 模式，通过预留资源的方式实现分布式事务。

优点：

强一致性保证
无锁设计，并发性能好
支持长事务

缺点：

业务侵入性强
需要设计预留资源逻辑
实现复杂度较高

假设我们有一个订单服务 (order-service) 和一个库存服务(stock-service)，创建订单时需要同时扣减库存。

// 订单服务 Try 接口
@PostMapping("/order/try")
public ResponseEntity<String> tryCreateOrder(@RequestBody OrderDTO orderDTO) {// 1. 冻结订单金额(实际业务中可能是预扣款)
    accountService.freeze(orderDTO.getUserId(), orderDTO.getAmount());

    // 2. 预创建订单状态为 "处理中"
    orderMapper.insertTemporary(orderDTO);

    // 3. 调用库存服务 Try 接口
    stockFeignClient.tryDeduct(orderDTO.getProductId(), orderDTO.getQuantity());

    return ResponseEntity.ok("try success");
}

// 库存服务 Try 接口
@PostMapping("/stock/try")
public ResponseEntity<String> tryDeduct(@RequestParam Long productId, 
                                       @RequestParam Integer quantity) {
    // 预扣减库存
    int affected = stockMapper.freezeStock(productId, quantity);
    if (affected == 0) {throw new RuntimeException("库存不足");
    }
    return ResponseEntity.ok("try success");
}

// 订单服务 Confirm 接口
@PostMapping("/order/confirm")
public ResponseEntity<String> confirmOrder(@RequestParam Long orderId) {
    // 1. 确认订单状态为 "已创建"
    orderMapper.confirm(orderId);

    // 2. 实际扣款
    accountService.confirm(orderId);

    // 3. 调用库存服务 Confirm 接口
    stockFeignClient.confirmDeduct(orderId);

    return ResponseEntity.ok("confirm success");
}

// 库存服务 Confirm 接口
@PostMapping("/stock/confirm")
public ResponseEntity<String> confirmDeduct(@RequestParam Long orderId) {
    // 实际扣减已冻结库存
    stockMapper.confirmDeduct(orderId);
    return ResponseEntity.ok("confirm success");
}

// 订单服务 Cancel 接口
@PostMapping("/order/cancel")
public ResponseEntity<String> cancelOrder(@RequestParam Long orderId) {
    // 1. 取消订单
    orderMapper.cancel(orderId);

    // 2. 解冻金额
    accountService.cancel(orderId);

    // 3. 调用库存服务 Cancel 接口
    stockFeignClient.cancelDeduct(orderId);

    return ResponseEntity.ok("cancel success");
}

// 库存服务 Cancel 接口
@PostMapping("/stock/cancel")
public ResponseEntity<String> cancelDeduct(@RequestParam Long orderId) {
    // 释放冻结的库存
    stockMapper.cancelDeduct(orderId);
    return ResponseEntity.ok("cancel success");
}

所有 Try/Confirm/Cancel 接口都必须实现幂等，防止网络重试导致重复执行。

// 幂等性处理示例
@Transactional
public void confirmOrder(Long orderId) {Order order = orderMapper.selectById(orderId);
    if (order == null) {throw new RuntimeException("订单不存在");
    }

    // 只有处理中状态的订单才能确认
    if (!"PROCESSING".equals(order.getStatus())) {return;}

    // 更新状态为已确认
    orderMapper.updateStatus(orderId, "CONFIRMED");
}

防止 Cancel 比 Try 先执行导致资源无法释放的情况。解决方案：