数据库事务传播机制与实战场景分析

数据库事务传播机制与实战场景分析：从理论到避坑指南

你好，我是源码库的一名技术博主。今天，我想和你深入聊聊一个在业务开发中至关重要，却又常常被“想当然”处理的概念——Spring事务的传播机制。记得我刚工作时，就因为对`@Transactional`的传播行为理解不透彻，导致线上出现了一个诡异的“部分回滚”Bug，排查了大半天。所以，这篇文章我会结合自己的实战经验和踩过的坑，带你彻底搞懂它。

事务传播机制（Propagation）解决的，简单说就是“当一个事务方法被另一个事务方法调用时，事务该如何进行”？是沿用老事务？还是开个新事务？或者干脆不用事务？Spring定义了七种传播行为，但最核心、最常用的其实就三四种。理解它们，是写出健壮数据操作代码的基石。

一、核心传播行为解读：不只是记住名字

我们先快速过一下最关键的几种传播行为，我会用最直白的语言解释：

• REQUIRED（默认）：如果当前存在事务，就加入该事务；如果当前没有事务，则创建一个新事务。这是最常用的，符合大多数业务场景。
• REQUIRES_NEW：无论如何都会创建一个新事务。如果当前存在事务，则把当前事务挂起。这意味着新事务与旧事务完全独立，新事务的提交和回滚不会影响旧事务，反之亦然。
• NESTED：如果当前存在事务，则在当前事务的一个嵌套事务（保存点）内执行。嵌套事务是外部事务的一部分，只有外部事务提交时它才会提交。它的独特之处在于可以部分回滚：嵌套事务回滚不影响外部事务，但外部事务回滚会导致嵌套事务也回滚。
• SUPPORTS：支持当前事务，如果当前没有事务，就以非事务方式执行。
• NOT_SUPPORTED：以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
• MANDATORY：强制要求当前存在事务，如果不存在，就抛出异常。
• NEVER：强制要求当前不能存在事务，如果存在，就抛出异常。

是不是有点抽象？别急，我们通过代码和场景来感受。

二、实战场景与代码演绎：REQUIRED vs REQUIRES_NEW

假设我们有一个用户注册服务，注册时需要记录用户主信息（User）和初始化他的积分账户（Points）。但积分初始化可能失败，我们希望：即使积分初始化失败，用户主信息也必须成功保存。这是一个典型的需要“子操作独立事务”的场景。

错误示范（使用默认REQUIRED）：

@Service
public class UserService {
    @Autowired
    private UserDao userDao;
    @Autowired
    private PointsService pointsService;

    @Transactional // 默认 Propagation.REQUIRED
    public void registerUser(User user) {
        // 1. 保存用户主信息
        userDao.save(user);
        // 2. 初始化积分账户
        pointsService.initPoints(user.getId()); // 这个方法内部也可能有@Transactional(REQUIRED)
    }
}

@Service
public class PointsService {
    @Transactional(propagation = Propagation.REQUIRED) // 加入registerUser的事务
    public void initPoints(Long userId) {
        // 模拟一个可能失败的操作，比如违反了数据库唯一约束
        pointsDao.createAccount(userId, 100);
        // 假设这里抛出了一个RuntimeException
        throw new RuntimeException("积分账户初始化失败");
    }
}

在这个例子中，由于`initPoints`方法使用了默认的`REQUIRED`，它会加入到`registerUser`开启的同一个事务中。当`initPoints`内部抛出运行时异常时，整个事务（包括之前已经执行的`userDao.save(user)`）会全部回滚！结果就是用户也没注册成功，这不符合我们的业务需求。

正确改造（使用REQUIRES_NEW）：

@Service
public class PointsService {
    @Transactional(propagation = Propagation.REQUIRES_NEW) // 关键在这里！
    public void initPoints(Long userId) {
        pointsDao.createAccount(userId, 100);
        throw new RuntimeException("积分账户初始化失败");
    }
}

现在，`initPoints`会在执行时，将`registerUser`的事务挂起，自己开启一个全新、独立的事务。当`initPoints`内部抛出异常导致其新事务回滚时，`registerUser`方法的事务（只包含保存用户的操作）并不会被回滚。用户注册成功，只是积分账户没有建立。我们可以在`registerUser`方法中捕获`initPoints`的异常，记录日志或进行其他补偿操作，保证了核心流程的顺畅。

踩坑提示： `REQUIRES_NEW`虽然好用，但不能滥用。因为它会真正开启一个新数据库连接（或从连接池获取新连接），如果在一个大循环里调用，会导致连接数暴增，有性能风险。同时，事务的挂起和恢复也有开销。

三、嵌套事务（NESTED）的微妙之处

`NESTED`和`REQUIRES_NEW`有点像，都是“内部事务”。但它们的本质区别在于：`NESTED`是外部事务的子事务，依赖于外部事务；而`REQUIRES_NEW`是两个平级、完全无关的事务。

它的经典场景是：批量处理，允许单条失败。比如批量导入商品数据，我们希望某一条数据格式错误时，只回滚这一条，其他成功条目继续提交。

@Transactional
public void batchImportProducts(List productList) {
    for (Product product : productList) {
        try {
            productService.importSingleProduct(product);
        } catch (DataIntegrityViolationException e) {
            // 捕获单条导入的异常，记录到错误日志，继续下一条
            log.error("导入商品失败: {}", product.getSku(), e);
        }
    }
}

@Service
public class ProductService {
    @Transactional(propagation = Propagation.NESTED) // 使用嵌套事务
    public void importSingleProduct(Product product) {
        productDao.save(product);
        // 可能触发唯一键冲突等异常
    }
}

这里，`importSingleProduct`方法在一个嵌套事务（保存点）中执行。如果它失败回滚，只会回滚到本次循环开始时的保存点，`batchImportProducts`主事务和其他成功条目的操作不受影响。最终，主事务提交时，所有成功的嵌套事务才会被真正提交。

重要限制： `NESTED`传播行为需要底层数据库支持保存点（Savepoint），比如MySQL的InnoDB引擎就支持。而像Oracle等数据库也支持。但请注意，JDBC驱动和Spring的版本兼容性也要确认。

四、其他行为的适用场景

• SUPPORTS：适用于查询方法。比如一个通用的`getById`方法，如果被一个事务方法调用，就加入事务保证一致性读（如可重复读隔离级别下的视图）；如果单独被调用，则无需事务开销。
• NOT_SUPPORTED：强制让方法不在事务中运行。经典场景是执行一些耗时很长、不需要事务的批量日志记录或消息发送操作，避免长时间占用数据库连接，拖慢主事务。
• MANDATORY：用于强制要求必须在事务中调用的方法，是一种防御性编程。比如进行资金核心扣减的操作，如果不在事务里调用就直接报错，防止脏数据。
• NEVER：与MANDATORY相反，强制要求不能在事务中调用。比如一些数据清理工具方法，确保自己执行时不会被外部事务干扰。

五、避坑总结与最佳实践

1. 默认值陷阱：不要忘记`@Transactional`默认就是`REQUIRED`和`RuntimeException`回滚。如果你希望检查型异常也回滚，需明确指定`rollbackFor`。

2. 自调用失效：Spring事务基于AOP代理，同一个类内部的方法A调用方法B，B上的`@Transactional`注解会失效！因为代理对象是外部注入的`this`，而内部调用走的是真实的`this`。解决方法：将方法B拆到另一个Service，或使用`AopContext.currentProxy()`（不推荐，有侵入性）。

3. 异常被“吃掉”：如果你在事务方法中捕获了异常却没有再次抛出，事务管理器将感知不到异常，从而不会触发回滚。

@Transactional
public void update() {
    try {
        // ... 数据库操作
        throw new RuntimeException();
    } catch (Exception e) {
        // 糟糕！异常被捕获了，事务不会回滚！
        log.error("error", e);
    }
}

4. 选择合适的传播行为：在设计方法时，就要思考它的边界。是核心的、不可分割的原子操作吗？用`REQUIRED`。是需要独立于主流程的辅助操作吗？考虑`REQUIRES_NEW`。是批量处理中的可失败子项吗？评估`NESTED`。

5. 结合隔离级别一起考虑：传播行为定义了事务的边界和创建方式，而隔离级别定义了事务内数据的可见性和并发影响。两者需要结合业务场景（如对脏读、幻读的容忍度）一起设计。

希望这篇结合实战的分析，能帮你把Spring事务传播机制从模糊的概念，变成清晰可用的设计工具。理解它们，下次设计服务层方法时，你就能更有底气地写下那个`@Transactional`注解了。编码愉快！