微服务架构下事务传播模式的深度抉择：REQUIRED与REQUIRES_NEW的黄金法则

当订单服务调用日志服务时，日志记录失败是否应该让整个订单创建流程回滚？这个看似简单的技术决策背后，隐藏着分布式系统事务一致性与业务容错性的复杂博弈。在微服务架构中，事务传播行为的选择直接影响着系统的健壮性和数据可靠性，而大多数开发者对@Transactional的认知仍停留在基础用法层面。

1. 事务传播机制的本质解析

事务传播行为（Transaction Propagation）是Spring框架对数据库事务嵌套调用场景的抽象解决方案。它定义了当一个事务方法被另一个事务方法调用时，事务应该如何传播的规则。理解这些规则的核心在于把握两个关键维度：事务上下文传递和异常处理边界。

在Spring定义的七种传播行为中，最常用的两种模式形成了鲜明对比：

public enum Propagation {
    REQUIRED(0),  // 支持当前事务，不存在则新建
    REQUIRES_NEW(3) // 新建事务，挂起当前事务
}

REQUIRED的典型特征：

• 默认传播级别，适用于大多数业务场景
• 内部方法加入外部方法的事务上下文
• 任意环节异常导致整个事务链回滚
• 仅需单个数据库连接，资源占用低

REQUIRES_NEW的核心特点：

• 每次调用都启动独立事务
• 挂起外部事务直至内部事务完成
• 需要维护多个数据库连接
• 内部事务回滚不影响外部事务

关键洞察：REQUIRED模式下的所有操作处于同一个原子单元，而REQUIRES_NEW创建的是逻辑上独立的工作单元。

2. 微服务场景下的模式选择矩阵

2.1 必须使用REQUIRED的典型场景

当业务操作需要严格的原子性保证时，REQUIRED是唯一正确的选择。以下是三个经典用例：

1. 订单支付流程：

   • 支付记录创建
   • 库存扣减
   • 积分增加
   • 这些操作必须全部成功或全部失败

2. 银行转账操作：

   • 转出账户扣款
   • 转入账户加款
   • 交易流水记录

3. 医疗系统处方开具：

   • 处方主记录
   • 药品明细
   • 医保结算信息

-- 典型的事务日志序列
BEGIN;
  -- 主订单表插入
  INSERT INTO orders VALUES(...);
  -- 订单明细插入
  INSERT INTO order_items VALUES(...);
  -- 库存更新
  UPDATE inventory SET stock = stock - 1 WHERE sku_id = 'X123';
COMMIT;

2.2 适合REQUIRES_NEW的业务场景

当某些辅助性操作不应该影响核心业务流程时，REQUIRES_NEW展现出其独特价值：

场景类型	示例	隔离必要性
日志记录	操作审计日志	日志失败不应中断交易
数据统计	用户行为分析	分析异常不影响功能
消息通知	订单状态提醒	发送失败不撤销订单
缓存更新	商品信息刷新	缓存异常不阻断写入

在电商系统中，一个典型的REQUIRES_NEW应用是订单创建后触发营销活动计算：

@Transactional
public void createOrder(OrderDTO dto) {
    // 核心订单逻辑
    orderRepository.save(dto);  // REQUIRED事务
    
    try {
        marketingService.calculateRewards(dto.getUserId()); // REQUIRES_NEW
    } catch (Exception e) {
        log.error("营销计算失败", e);
    }
}

3. 性能影响与潜在陷阱

3.1 连接资源消耗对比

事务传播模式的选择直接影响数据库连接池的使用效率：

• REQUIRED模式：

  • 单个方法调用链共享一个连接
  • 连接占用时间=最外层方法开始到结束
  • 适合短平快的操作链

• REQUIRES_NEW模式：

  • 每个新事务获取独立连接
  • 连接占用时间=各事务持续时间总和
  • 可能导致连接池耗尽

压力测试数据表明：在高并发场景下，不当使用REQUIRES_NEW可能使连接等待时间增加300%-500%。

3.2 死锁风险与解决方案

REQUIRES_NEW在特定场景下可能引发死锁问题，特别是在处理相同数据时：

1. 典型死锁场景：

   • 事务A锁定记录R1
   • 事务B(REQUIRES_NEW)尝试锁定R2
   • 事务B需要R1，事务A需要R2
   • 形成循环等待

2. 预防措施：

   • 统一锁获取顺序
   • 减少REQUIRES_NEW事务持锁时间
   • 使用乐观锁替代悲观锁
   • 设置合理的事务超时时间

@Transactional(propagation = Propagation.REQUIRES_NEW, 
               timeout = 5) // 设置5秒超时
public void auditLog(Action action) {
    // 快速完成日志记录
}

4. 工程实践中的决策框架

4.1 事务选择的四象限法则

基于业务影响和失败概率两个维度，我们可以建立决策矩阵：

	高业务影响	低业务影响
高失败概率	避免事务/补偿机制	REQUIRES_NEW+重试机制
低失败概率	REQUIRED+完善异常处理	REQUIRES_NEW+简单日志记录

4.2 混合模式的最佳实践

在实际复杂业务中，往往需要混合使用两种传播模式：

1. 核心链路：采用REQUIRED保证原子性
2. 辅助功能：使用REQUIRES_NEW隔离风险
3. 关键校验：REQUIRED确保一致性
4. 后续处理：REQUIRES_NEW实现异步效果

@Transactional
public void completePayment(PaymentRequest request) {
    // 核心支付处理(REQUIRED)
    paymentCoreService.process(request);  
    
    // 风控检查(REQUIRED)
    riskControlService.validate(request);
    
    try {
        // 消息通知(REQUIRES_NEW)
        notificationService.sendReceipt(request); 
    } catch (Exception e) {
        log.warn("通知发送失败", e);
    }
}

在金融系统开发中，我们曾遇到一个典型案例：支付主流程采用REQUIRED，而交易风控检查虽然重要但可能超时，最终解决方案是将风控拆分为前置的REQUIRED校验和异步的REQUIRES_NEW深度分析，既保证了支付原子性，又避免了风控系统影响核心链路稳定性。