Spring事务传播行为解析与使用技巧

## Spring事务传播行为详解与实战应用：保障数据一致性的关键 Spring声明式事务的传播行为是控制多个事务方法相互调用时事务传递和影响的重要机制，对于保证数据一致性至关重要。本文深入解析Spring提供的七种传播行为：REQUIRED、SUPPORTS、MANDATORY、REQUIRES_NEW、NOT_SUPPORTED、NEVER以及NESTED，详细阐述每种行为的特性与适用场景。例如，REQUIRED适用于需要保证操作一致性的场景，而REQUIRES_NEW则适用于需要独立控制事务的场景。此外，文章还对比了NESTED与REQUIRES_NEW的区别，并提供了优化事务传播行为导致性能问题的实用技巧，如缩小事务范围、批量操作和异步处理等。掌握Spring事务传播行为，能有效避免数据不一致问题，更好地控制事务边界，提升系统稳定性和性能。

Spring声明式事务的传播行为定义了多个事务方法调用时事务如何传递。主要有7种类型：1. REQUIRED（默认，有事务则加入，无则新建）；2. SUPPORTS（存在事务则加入，否则非事务运行）；3. MANDATORY（必须有事务，否则抛异常）；4. REQUIRES_NEW（不管当前有无事务，都新建事务并挂起当前事务）；5. NOT_SUPPORTED（非事务运行，若存在则挂起）；6. NEVER（非事务运行，存在事务则抛异常）；7. NESTED（存在事务则创建子事务，否则新建）。例如，methodA使用REQUIRED，methodB使用REQUIRES_NEW，则methodB会挂起methodA事务并独立提交或回滚。选择依据是业务场景，如订单支付和积分增加需一致性则选REQUIRED，否则用REQUIRES_NEW。NESTED与REQUIRES_NEW的区别在于前者是外部事务的子事务，回滚会联动，后者是独立事务。性能问题可通过缩小事务范围、批量操作、异步处理、读写分离等方式优化。

Spring声明式事务的传播行为，简单来说，就是多个事务方法相互调用时，事务如何传递和影响。掌握它，能避免数据不一致，也能更好地控制事务边界。

解决方案

Spring的声明式事务传播行为定义了当一个事务方法被另一个事务方法调用时，事务应该如何传播。主要有以下几种传播行为：

• REQUIRED (默认): 如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。这是最常用的传播行为。
• SUPPORTS: 如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务方式继续运行。
• MANDATORY: 如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。
• REQUIRES_NEW: 无论当前是否存在事务，都会创建一个新的事务，并且将当前事务挂起。
• NOT_SUPPORTED: 以非事务方式运行，如果当前存在事务，则将当前事务挂起。
• NEVER: 以非事务方式运行，如果当前存在事务，则抛出异常。
• NESTED: 如果当前存在事务，则创建一个嵌套事务作为当前事务的子事务；如果当前没有事务，则创建一个新的事务。

举个例子，假设我们有两个Service，ServiceA和ServiceB，ServiceA的方法methodA调用ServiceB的方法methodB。我们可以通过@Transactional注解来配置它们的传播行为。

@Service
public class ServiceA {

    @Autowired
    private ServiceB serviceB;

    @Transactional(propagation = Propagation.REQUIRED)
    public void methodA() {
        // ... 一些操作
        serviceB.methodB();
        // ... 另一些操作
    }
}

@Service
public class ServiceB {

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void methodB() {
        // ... 一些操作
    }
}

在这个例子中，methodA的传播行为是REQUIRED，methodB的传播行为是REQUIRES_NEW。这意味着，当methodA被调用时，如果当前没有事务，Spring会创建一个新的事务。然后，methodA调用methodB，由于methodB的传播行为是REQUIRES_NEW，Spring会创建一个新的事务，并且将methodA的事务挂起。如果methodB中的操作失败，只会回滚methodB的事务，而不会影响methodA的事务。反之，如果methodA失败，会回滚methodA的事务，methodB的事务如果已经提交，则不受影响。

选择合适的传播行为需要根据具体的业务场景来决定。例如，如果需要保证多个操作要么全部成功，要么全部失败，可以选择REQUIRED。如果需要独立控制某个操作的事务，可以选择REQUIRES_NEW。

传播行为的选择依据：业务场景决定一切

很多时候，我们纠结于到底用哪个传播行为，本质上是对业务理解不够透彻。比如，订单支付和积分增加，如果积分增加失败不应该影响订单支付，那就REQUIRES_NEW，反之，如果必须保证两者一致性，那就REQUIRED。

嵌套事务（NESTED）和REQUIRES_NEW的区别是什么？

NESTED和REQUIRES_NEW都是创建新事务，但区别在于：NESTED事务是当前事务的子事务，依赖于当前事务存在。如果外部事务回滚，嵌套事务也会回滚。而REQUIRES_NEW是完全独立的事务，外部事务的回滚不会影响它，反之亦然，前提是REQUIRES_NEW的事务已经提交。

可以把NESTED想象成一个保存点，外部事务可以回滚到这个保存点，而REQUIRES_NEW则是一个完全独立的提交单元。

如何处理事务传播行为导致的性能问题？

过度使用REQUIRES_NEW可能会导致性能问题，因为每次都会创建一个新的事务，涉及到连接的获取和释放。可以考虑以下几个方面：

1. 减少事务范围： 尽可能缩小事务的范围，避免不必要的操作包含在事务中。
2. 批量操作： 将多个操作合并成一个批量操作，减少事务的数量。
3. 异步处理： 将一些非核心的操作异步处理，避免阻塞主事务。
4. 读写分离： 如果存在大量的读操作，可以考虑读写分离，将读操作从主事务中分离出来。

另外，也要注意数据库连接池的配置，确保连接池的大小能够满足并发需求。

今天关于《Spring事务传播行为解析与使用技巧》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！