Spring Boot 事务管理：实战案例解析

在分布式系统与高并发场景下，事务管理是保障数据一致性的核心机制。Spring Boot 通过简化的配置与强大的抽象能力，为开发者提供了灵活的事务管理工具。然而，面对复杂的业务场景（如分布式事务、嵌套事务、高并发控制等），仅了解基础用法远远不够。本文将通过 4 个典型实战案例，深入剖析事务管理的核心原理与高级技巧，并提供可直接复用的代码模板。

一、订单创建与库存扣减：事务的原子性保障

1.1 场景描述
在电商系统中，用户下单需同时完成 订单创建 与 库存扣减，任一操作失败都必须回滚。此场景需严格保障操作的原子性。

1.2 解决方案
使用 @Transactional 注解管理事务边界，结合自定义异常实现回滚控制。

@Service
public class OrderService {

    @Autowired
    private OrderRepository orderRepository;

    @Autowired
    private InventoryService inventoryService;

    /**
     * 创建订单（事务方法）
     * @param orderDTO 订单传输对象
     * @throws BusinessException 业务异常时回滚事务
     */
    @Transactional(rollbackFor = BusinessException.class)
    public void createOrder(OrderDTO orderDTO) throws BusinessException {
        try {
            // 1. 扣减库存（内部事务传播）
            inventoryService.deductStock(orderDTO.getProductId(), orderDTO.getQuantity());

            // 2. 生成订单
            Order order = convertToOrder(orderDTO);
            orderRepository.save(order);

            // 3. 模拟支付（失败则抛出异常）
            processPayment(order);
        } catch (InventoryException e) {
            throw new BusinessException("库存不足", e); // 触发回滚
        }
    }

    private void processPayment(Order order) throws PaymentException {
        if (order.getAmount().compareTo(BigDecimal.valueOf(5000)) > 0) {
            throw new PaymentException("单笔支付金额超限"); // 触发回滚
        }
        // 实际支付逻辑...
    }
}

关键点解析：

• @Transactional
  默认捕获 RuntimeException，此处通过 rollbackFor 显式指定回滚的异常类型
• 库存服务 deductStock 方法使用 REQUIRED 传播行为，加入当前事务上下文
• 支付异常触发事务回滚，确保订单与库存状态一致

二、用户注册审计日志：事务传播机制实战

2.1 场景描述
用户注册时需要记录审计日志，要求 日志记录必须成功（即使主事务回滚）。此场景需使用独立事务。

2.2 解决方案
采用 Propagation.REQUIRES_NEW 传播行为，确保日志事务独立提交。

@Service
public class UserService {

    @Autowired
    private UserRepository userRepository;

    @Autowired
    private AuditService auditService;

    @Transactional
    public void registerUser(User user) {
        try {
            // 1. 保存用户（主事务）
            userRepository.save(user);

            // 2. 记录审计日志（独立事务）
            auditService.logRegistration(user.getId());
        } catch (DataIntegrityViolationException e) {
            throw new RegistrationException("用户已存在", e); // 主事务回滚
        }
    }
}

@Service
public class AuditService {

    /**
     * 记录审计日志（独立事务）
     */
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void logRegistration(Long userId) {
        AuditLog log = new AuditLog("USER_REGISTER", userId);
        auditLogRepository.save(log); // 即使主事务回滚，此操作仍提交
    }
}

执行流程：

• 主事务开启
• 用户保存成功
• 开启新事务保存日志
• 若主事务后续失败回滚，日志事务已独立提交

三、账户余额批量转账：事务隔离与并发控制

3.1 场景描述
批量处理 1000 个账户转账时，需避免 脏读 与 死锁，同时保证高并发性能。

3.2 解决方案
结合 乐观锁（Optimistic Locking） 与 批量操作优化，选择 READ_COMMITTED 隔离级别。

@Service
public class BatchTransferService {

    @Autowired
    private AccountRepository accountRepository;

    /**
     * 批量转账（带版本控制的乐观锁）
     */
    @Transactional(isolation = Isolation.READ_COMMITTED, timeout = 30)
    public void batchTransfer(List<TransferRequest> requests) {
        requests.forEach(request -> {
            // 1. 查询账户（带版本号）
            Account from = accountRepository.findByIdWithLock(request.getFromId())
                    .orElseThrow(() -> new AccountNotFoundException("转出账户不存在"));
            Account to = accountRepository.findByIdWithLock(request.getToId())
                    .orElseThrow(() -> new AccountNotFoundException("转入账户不存在"));

            // 2. 校验并转账
            if (from.getBalance().compareTo(request.getAmount()) < 0) {
                throw new InsufficientBalanceException("余额不足");
            }
            from.debit(request.getAmount());
            to.credit(request.getAmount());

            // 3. 批量更新（带版本检查）
            accountRepository.updateBalance(from.getId(), from.getBalance(), from.getVersion());
            accountRepository.updateBalance(to.getId(), to.getBalance(), to.getVersion());
        });
    }
}

// JPA 实体类优化

@Entity
public class Account {
    @Id
    private Long id;
    private BigDecimal balance;

    @Version // 乐观锁版本字段
    private Integer version;

    // 省略 getter/setter
}

优化策略：

• 使用 @Version 实现乐观锁，避免脏写
• 通过 findByIdWithLock 自定义查询控制锁粒度
• 批量更新减少数据库交互次数

四、分布式订单支付：Seata 全局事务整合

4.1 场景描述
跨服务的订单支付涉及 订单服务、支付服务、库存服务，需保证跨服务事务一致性。

4.2 解决方案
集成 Seata 实现分布式事务，使用 @GlobalTransactional 注解。

Seata 配置（application.yml）：

seata:
  enabled: true
  application-id: order-service
  tx-service-group: my_tx_group
  service:
    vgroup-mapping:
      my_tx_group: default

业务代码实现：

@Service
public class DistributedOrderService {

    @Autowired
    private OrderService orderService;

    @Autowired
    private PaymentService paymentService;

    @Autowired
    private InventoryService inventoryService;

    /**
     * 全局分布式事务
     */
    @GlobalTransactional(name = "createOrderTx", timeoutMills = 30000)
    public void createOrderWithPayment(OrderRequest request) {
        // 1. 创建订单（本地事务）
        Order order = orderService.create(request);

        // 2. 调用支付服务（远程事务）
        paymentService.process(order.getId(), order.getAmount());

        // 3. 扣减库存（跨服务调用）
        inventoryService.deduct(order.getProductId(), order.getQuantity());
    }
}

执行流程：

• TM（事务管理器）向 TC（事务协调器）注册全局事务
• 各分支服务通过 UNDO_LOG 记录回滚日志
• 全部成功则提交，任一失败则全局回滚

五、事务监控与性能调优

5.1 监控配置
通过 Spring Boot Actuator 暴露事务指标：

management:
  endpoints:
    web:
      exposure:
        include: transactions,metrics
  metrics:
    tags:
      application: ${spring.application.name}

5.2 性能优化策略

6.1 核心原则
原子性设计
：事务边界应严格匹配业务操作单元
隔离选择
：根据业务容忍度选择最低隔离级别（通常 READ_COMMITTED）
异常处理
：明确指定 rollbackFor 属性，避免意外提交
性能意识
：监控事务耗时，长事务必须优化拆分

6.2 实战技巧清单