spring事务配置

2026年9月2日 23:16 • 虚拟主机 • 阅读 93

Spring事务配置的关键在于优先使用声明式事务（基于@Transactional注解或XML），并将事务边界、传播行为、隔离级别、回滚规则四个要素统一规划，错误的配置会导致数据不一致、连接泄漏、性能下降，因此必须从业务场景出发，而不是盲目套用默认值。

Spring事务管理的基础认知

Spring事务抽象的核心是PlatformTransactionManager接口，它屏蔽了底层资源（JDBC、JPA、MyBatis等）的差异，对于单体应用，最常见的实现是DataSourceTransactionManager，对应Spring Boot中自动配置的JdbcTransactionManager。

事务配置的本质只有三件事：

开启事务：通过注解或XML声明边界。
控制行为：设置传播、隔离、超时、只读属性。
处理异常：定义哪些异常触发回滚，哪些不触发。

声明式事务配置详解

基于注解的配置（推荐）

在Spring Boot中，只需在启动类或配置类添加@EnableTransactionManagement，然后在业务方法上标注@Transactional，注意：

方法必须为public，且通过代理对象调用才生效。
自调用失效：同类内部this调用不会走代理，需注入自身或拆分Bean。
默认回滚规则：仅对RuntimeException和Error回滚，受检异常（Exception的子类）默认不回滚。

基于XML的配置

在传统Spring项目中,使用<tx:advice>

和<aop:config>组合，虽然注解更简洁，但XML适合需要批量统一规则的场景，例如给某个包下所有Service方法统一设置超时和只读。

<tx:advice id="txAdvice" transaction-manager="transactionManager">
    <tx:attributes>
        <tx:method name="get" read-only="true" propagation="SUPPORTS"/>
        <tx:method name="save" rollback-for="Exception"/>
    </tx:attributes>
</tx:advice>

事务传播行为与隔离级别实战

传播行为选择

7种传播行为中，最常用的是REQUIRED和REQUIRES_NEW。

REQUIRED（默认）：有事务则加入，无事务则新建，适用于绝大多数业务方法。
REQUIRES_NEW：挂起当前事务，新建独立事务，适用于日志记录、异步通知等必须独立提交/回滚的场景。
NESTED：利用保存点实现部分回滚，适合长流程中的“子任务失败不影响主流程”。

反例：在同一个事务内调用远程接口，远程处理耗时且可能失败，会导致数据库连接长期占用，应改为REQUIRES_NEW或异步非事务。

隔离级别与锁

MySQL默认REPEATABLE_READ，但高并发场景下需按业务权衡：

查询统计报表：用READ_UNCOMMITTED减少锁竞争，但不可用于资金类数据。
防止并发插入重复：用SERIALIZABLE

或配合唯一索引，不能只依赖事务隔离。
乐观锁方案：在实体加@Version，配合REQUIRED事务，比PESSIMISTIC_WRITE更适合大多数互联网业务。

回滚规则与常见坑

回滚配置的正确姿势

@Transactional(rollbackFor = Exception.class)public void createOrder(Order order) {    orderDao.insert(order);    stockService.deduct(order.getProductId(), order.getQuantity());}

显式声明rollbackFor = Exception.class，避免受检异常不回滚导致脏数据。
如果捕获异常后不抛出,事务将正常提交，这是最常见的“事务失效”原因。

事务失效的五个典型场景

数据库引擎不支持事务（如MyISAM）。
方法非public，或通过this调用。
类未被Spring管理（未标注@Service/@Component）。
异常被catch后未重新抛出。
使用了@Transactional但未配置事务管理器（多数据源时尤其容易遗漏）。

酷番云独家经验案例

场景：某电商系统在酷番云部署，订单创建服务涉及库存扣减、积分赠送、消息推送，最初全部放在一个REQUIRED事务中，导致以下问题：

消息推送调用第三方接口,响应超时后数据库连接被占用30秒，触发连接池耗尽。
积分赠送失败时,整个订单回滚，用户投诉“支付成功但订单消失”。

优化方案：

订单主流程保持REQUIRED，只操作本库的订单表和库存表。
积分赠送改为REQUIRES_NEW，失败仅记录日志，不影响订单提交。
消息推送移出事务,通过酷番云提供的可靠消息服务（基于本地消息表+定时任务）异步发送。

效果：事务耗时从平均800ms降至120ms，连接池占用下降70%，订单成功率提升至99.99%，此方案也适用于在酷番云上使用MySQL高可用版的企业，减少长事务带来的主从延迟风险。

spring事务配置

Spring事务管理的基础认知