事务传播机制使用场景

事务传播机制使用场景

大家好，我是程序员老张。今天咱们聊一个面试高频考点——事务传播机制的使用场景。很多同学被问到"Spring事务传播行为有哪些"时能背出7种类型，但被追问"实际开发中怎么用"就卡壳了。别急，我结合真实业务场景用大白话给你们捋清楚。

先分享个福利：2025年Java面试宝典
链接: <span style="color:blue">https://pan.baidu.com/s/1RUVf75gmDVsg8MQp4yRChg?pwd=9b3g</span>
提取码: 9b3g （建议保存，涵盖30+大厂真题）

什么是事务传播机制

简单说就是：多个事务方法互相调用时，事务该怎么传递。比如方法A调方法B，B是沿用A的事务？还是自己新开事务？这就是传播机制要解决的问题。Spring定义了7种行为，但实际开发中主要用这3种：

1. REQUIRED（最常用场景）

核心逻辑：如果当前有事务就加入，没有就新建。
真实业务场景：
比如电商下单流程：

下单主方法(orderService.createOrder)  
   └── 扣库存方法(stockService.deduct)  
   └── 生成日志方法(logService.record)  

这仨方法必须同生共死——库存扣了但日志失败？整个订单要回滚！此时用REQUIRED最稳妥，三个操作在同一个事务里执行。

面试官追问："为什么不用REQUIRES_NEW？" 直接答：如果拆成三个独立事务，扣库存成功了但日志失败，库存不会回滚，导致数据不一致！

2. REQUIRES_NEW（关键操作隔离）

核心逻辑：老子直接开新事务，旧事务一边凉快去！
真实业务场景：
财务系统有个核心需求：操作日志必须100%留存。哪怕转账失败了，操作记录也得存库。这时候：

转账方法(transferService.execute)  
   └── 记审计日志(auditService.log)  

给log()配置REQUIRES_NEW，即使转账失败抛异常，审计日志的事务也会单独提交，不会被回滚带跑偏。

3. NESTED（子操作灵活回滚）

核心逻辑：在已有事务里开个"子事务"，主事务回滚会带飞子事务，但子事务可以自己单独回滚。
真实业务场景：
批量导入用户数据时：

批量导入(importService.batchImport)  
   ├── 校验用户A(validateUserA)  
   ├── 校验用户B(validateUserB)  
   └── 写入DB(insertToDB)  

用NESTED配置校验方法：当用户B校验失败时，只回滚B的操作，用户A的校验结果还能保留，主事务继续执行后续逻辑。

其他传播行为一句话场景

• SUPPORTS：查询日志方法，有事务就跟，没有就裸奔（适合非核心查询）
• NOT_SUPPORTED：给短信通知服务用，死活不参与事务（避免短信服务拖垮主事务）
• NEVER：关键数据计算，发现有人开事务直接掀桌报错（防止被意外卷入事务）
• MANDATORY：支付回调方法，必须由上游事务调用（避免裸奔执行）

面试避坑指南

被问到"选错传播行为会怎样？" 举个血案：
某P2P系统用REQUIRED调用风控服务，结果风控接口超时拖垮主事务，导致10万订单卡死... 正确做法：用NOT_SUPPORTED把风控调用踢出事务！

重要提示：需要购买面试鸭会员的同学，通过面试鸭返利网找我可返25元，已帮137人省下会员费。

最后划重点

1. REQUIRED是默认选项，适用于80%的增删改场景
2. REQUIRES_NEW为关键操作上保险（审计/日志）
3. NESTED在批量处理中实现局部回滚
   记住这个口诀：同生共死用REQUIRED，保命要紧REQUIRES_NEW，灵活回滚NESTED秀

搞懂这些事务传播机制使用场景，面试时遇到事务相关题直接拿捏。更多实战案例在开头分享的面试宝典里，记得下载保存！