事务回滚标记：深入剖析Transaction rolled back because it has been marked as rollback-only的根源与实战规避

1. 事务回滚标记的典型场景剖析

第一次看到"Transaction rolled back because it has been marked as rollback-only"这个错误时，很多开发者都会感到困惑。明明已经用try-catch捕获了所有异常，为什么事务还是回滚了？这就像是你以为已经关掉了水龙头，但地下室还是被淹了——肯定有什么关键机制被你忽略了。

在实际项目中，这种情况通常出现在嵌套事务的场景中。比如你在用户注册的主业务流程里调用了发送邮件的子方法，两个方法都加了@Transactional注解。当发送邮件失败时，即使你在主方法里捕获了这个异常，整个注册流程的事务依然会回滚。这是因为Spring的事务管理器在底层维护了一个"rollback-only"的状态标记，一旦这个标记被设置，就像打开了单向阀门，事务只能向回滚的方向流动。

2. Spring事务状态机的运作原理

2.1 事务传播机制的核心设计

Spring的事务管理本质上是一个状态机，REQUIRED(默认)传播级别下，嵌套的@Transactional方法会共享同一个物理事务。当内层方法抛出异常时，事务管理器会做两件事：首先将异常转换为RollbackRuleAttribute匹配的规则，然后将事务标记为rollback-only。这个标记就像交通信号灯，一旦变红就无法再变绿。

我曾在电商项目中遇到过这样的案例：订单服务调用库存服务时，库存服务抛出了异常但被订单服务捕获。理论上订单应该能创建成功，但实际上整个事务都回滚了。通过调试发现，在DefaultTransactionStatus类中有个isRollbackOnly标志位，这个标志位一旦被设置为true就无法再修改。

2.2 事务状态的生命周期

理解事务状态流转对解决这类问题至关重要。一个Spring事务的生命周期大致如下：

1. 事务开启时创建TransactionStatus实例
2. 执行过程中遇到异常会检查回滚规则
3. 匹配到回滚规则则设置rollback-only=true
4. 提交时检查rollback-only标志位
5. 如果为true则强制回滚并抛出异常

关键点在于：rollback-only标志位的设置是不可逆的。就像烧断的保险丝，即使你修好了电路，保险丝也不会自动恢复。

3. 深度解析rollback-only的产生条件

3.1 显式与隐式标记场景

rollback-only标记可以通过两种方式设置：

显式设置：

java复制// 在代码中主动标记事务需要回滚
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();

隐式设置：

java复制@Transactional
public void innerMethod() {
    // 抛出RuntimeException或其子类
    throw new BusinessException("业务异常");
}

在我的性能调优实践中发现，隐式设置更常见但更难排查。特别是当使用第三方库时，某些你以为已经处理的异常可能仍然触发了rollback-only标记。

3.2 异常类型与回滚规则

Spring默认只对RuntimeException和Error进行回滚，这是很多开发者踩坑的地方。比如下面这个例子：

java复制@Transactional
public void process() throws Exception {
    try {
        someOperation();
    } catch (IOException e) {
        // 虽然捕获了但事务可能已经回滚
        throw new Exception(e);
    }
}

如果someOperation()内部抛出了RuntimeException，即使外层捕获了Exception，事务依然会被标记为rollback-only。正确的做法是明确指定@Transactional的rollbackFor属性。

4. 实战解决方案与最佳实践

4.1 传播级别的选择策略

针对不同的业务场景，可以选用不同的事务传播级别：

1. REQUIRES_NEW：适合需要完全独立的事务，如日志记录

java复制@Transactional(propagation = Propagation.REQUIRES_NEW)
public void auditLog() {
    // 即使主事务回滚，日志也会保留
}

2. NESTED：创建保存点，部分回滚

java复制@Transactional(propagation = Propagation.NESTED)
public void updateInventory() {
    // 如果失败只回滚这部分操作
}

3. NOT_SUPPORTED：挂起当前事务

java复制@Transactional(propagation = Propagation.NOT_SUPPORTED)
public void sendNotification() {
    // 不在事务中执行
}

在金融项目中，我们使用REQUIRES_NEW来处理对账流程，确保即使主交易失败，对账记录也能完整保存。

4.2 异常处理的正确姿势

正确的异常处理应该考虑事务边界：

java复制@Transactional
public void placeOrder(Order order) {
    try {
        inventoryService.reduceStock(order); // REQUIRES_NEW
        paymentService.processPayment(order); // REQUIRES_NEW
        orderDao.save(order);
    } catch (Exception e) {
        // 标记当前事务需要回滚
        TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
        // 记录详细错误信息
        errorLogService.logError(e); // NOT_SUPPORTED
        throw new OrderException("下单失败", e);
    }
}

这种模式确保了：1) 子事务独立；2) 主事务可控；3) 错误日志必录。

5. 复杂场景下的调试技巧

5.1 事务调试工具的使用

当遇到复杂的事务问题时，可以启用Spring的调试日志：

properties复制logging.level.org.springframework.transaction.interceptor=TRACE
logging.level.org.springframework.orm.jpa.JpaTransactionManager=DEBUG

在日志中搜索"Participating in existing transaction"或"Creating new transaction"可以帮助理解事务的创建和加入过程。

5.2 事务边界可视化

我习惯使用简单的ASCII图来理清事务边界：

code复制[主事务REQUIRED]
    |
    |-- [子事务REQUIRES_NEW] (独立提交回滚)
    |
    |-- [子事务REQUIRED] (共享rollback-only标记)
    |
    |-- [子事务NOT_SUPPORTED] (非事务执行)

这种方法在代码评审时特别有用，能快速识别潜在的事务传播问题。

6. 架构层面的预防措施

6.1 事务划分原则

根据领域驱动设计，我们应该遵循以下事务划分原则：

1. 聚合根作为事务边界
2. 跨聚合操作使用最终一致性
3. 查询操作禁用事务
4. 后台任务使用独立事务

例如在用户注册流程中：

java复制// 用户聚合
@Transactional
public User register(User user) {
    // 用户数据校验和保存
}

// 异步事件处理
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void sendWelcomeEmail(User user) {
    // 发送欢迎邮件
}

6.2 事务监控与告警

在生产环境中，建议配置事务监控：

1. 记录长时间运行的事务
2. 监控事务回滚率
3. 设置嵌套事务深度阈值

我们使用Micrometer实现的监控示例：

java复制@Bean
public TransactionMetrics transactionMetrics(PlatformTransactionManager tm) {
    return new TransactionMetrics(tm, 
        Tags.of("application", "order-service"));
}

这套系统曾帮助我们及时发现并解决了分布式事务超时问题。