在 Spring 中进行事务管理非常简单,只需要在方法上加上注解 @Transactional
,Spring就可以自动帮我们进行事务的开启、提交、回滚操作。甚至很多人心里已经将
Spring 事务与 @Transactional
划上了等号,只要有数据库相关操作就直接给方法加上 @Transactional
注解。
一. @Transactional 导致的生产事故
2019年在公司做了一个内部报销的项目,有这样一个业务逻辑:
员工加班打车可以通过滴滴出行企业版直接打车,第二天打车费用可以直接同步到我们的报销平台;
员工可以在报销平台勾选自己打车费用并创建一张报销单进行报销,创建报销单的同时会创建一条审批流(统一流程平台)让领导审批。
当时创建报销单的代码是这么写的:
/**
* 保存报销单并创建工作流
*/
@Transactional(rollbackFor = Exception.class)
public void save(RequestBillDTO requestBillDTO) {
// 调用流程HTTP接口创建工作流
workflowUtil.createFlow("BILL", requestBillDTO);
// 转换DTO对象
RequestBill requestBill = JkMappingUtils.convert(requestBillDTO, RequestBill.class);
requestBillDao.save(requestBill);
// 保存明细表
requestDetailDao.save(requestBill.getDetail());
}
代码非常简单也很“优雅“,先通过Http接口调用工作流引擎创建审批流,然后保存报销单,而为了保证操作的事务,在整个方法上加上了 @Transactional
注解(仔细想想,这样真的能保证事务吗?)。
报销项目属于公司内部项目,本身是没什么高并发的,系统也一直稳定运行着。
在年末的一天下午(前几天刚好下了大雪,打车的人特别多),公司发通知邮件说年度报销窗口即将关闭,需要尽快将未报销的费用报销掉,而刚好那天工作流引擎在进行安全加固。
收到邮件后报销的人开始逐渐增多,在接近下班的时候到达顶峰,此时报销系统开始出现了故障:数据库监控平台一直收到告警短信,数据库连接不足,出现大量死锁;日志显示调用流程引擎接口出现大量超时;同时一直提示 CannotGetJdbcConnectionException
,数据库连接池连接占满。
在发生故障后,尝试过杀掉死锁进程,也进行过暴力重启,只是不到10分钟故障再次出现,最后没办法只能向全员发送停机维护邮件并发送故障报告。
二. 事故原因分析
通过对日志的分析我们很容易就可以定位到故障原因就是保存报销单的save()
方法,而罪魁祸首就是这个 @Transactional
事务注解。
我们知道 @Transactional
注解,是使用 AOP
实现的,本质就是在目标方法执行前后进行拦截。在目标方法执行前加入或创建一个事务,在执行方法执行后,根据实际情况选择提交或是回滚事务。
当 Spring 遇到该注解时,会自动从数据库连接池中获取 connection
,并开启事务然后绑定到 ThreadLocal 上,对于 @Transactional
注解包裹的整个方法都是使用同一个 connection
连接。如果我们出现了耗时的操作,比如第三方接口调用,业务逻辑复杂,大批量数据处理等就会导致我们我们占用这个 connection
的时间会很长,数据库连接一直被占用不释放。一旦类似操作过多,就会导致数据库连接池耗尽。
在一个事务中执行 RPC 操作导致数据库连接池被撑爆属于典型的长事务问题,类似的操作还有在事务中进行大量数据查询,业务规则处理等。
何为长事务?
顾名思义就是运行时间比较长,长时间未提交的事务,也可以称之为大事务。
长事务会引发哪些问题?
数据库连接池被占满,应用无法获取连接;
容易引发数据库死锁;
数据库回滚时间长;
在主从架构中会导致主从延时变大。
三. 如何避免长事务
既然知道了长事务的危害,那如何在开发中避免出现长事务问题呢?
很明显,解决长事务的办法就是对事务方法进行拆分,尽量让事务变小、变快,减小事务的颗粒度。
既然提到了事务的颗粒度,我们就先回顾一下 Spring 进行事务管理的方式。
声明式事务
所谓声明式事务,就是通过配置的方式,例如在方法上使用 @Transactional
注解或者 XML
配置文件进行事务管理的操作叫声明式事务。
声明式事务的优点:使用简单,Spring 可以自动帮我们进行事务的开启、提交以及回滚等操作。使用这种方式,开发人员只需要关注业务逻辑就可以了。
声明式事务的缺点:事务的颗粒度是整个方法,无法进行精细化控制。
编程式事务
与声明式事务对应的就是编程式事务。
基于底层的API,开发者在代码中手动管理事务的开启、提交、回滚等操作。在 Spring 项目中可以使用 TransactionTemplate
类的对象,手动控制事务。
@Autowired
private TransactionTemplate transactionTemplate;
public void save(RequestBill requestBill) {
transactionTemplate.execute(transactionStatus -> {
requestBillDao.save(requestBill);
// 保存明细表
requestDetailDao.save(requestBill.getDetail());
return Boolean.TRUE;
});
}
使用编程式事务最大的好处就是可以精细化控制事务范围。
所以避免长事务最简单的方法就是不要使用声明式事务注解 @Transactional
,而是使用编程式事务手动控制事务范围。
大家可能会说,@Transactional
使用这么简单,有没有办法既可以使用 @Transactional
,又能避免产生长事务?
那就需要对方法进行拆分,将不需要事务管理的逻辑与事务操作分开:
@Service
public class OrderService {
public void createOrder(OrderCreateDTO createDTO) {
query();
validate();
saveData(createDTO);
}
// 事务操作
@Transactional(rollbackFor = Throwable.class)
public void saveData(OrderCreateDTO createDTO) {
orderDao.insert(createDTO);
}
}
query()
与 validate()
不需要事务,我们将其与事务方法 saveData()
拆开。
当然,这种拆分会命中使用 @Transactional
注解时事务不生效的经典场景,很多新手非常容易犯这个错误。@Transactional
注解的声明式事务是通过 Spring AOP 起作用的,而 Spring AOP 需要生成代理对象,直接在同一个类中方法调用使用的还是原始对象,事务不生效。其他几个常见的事务不生效场景为:
- @Transactional 应用在非
public
修饰的方法上- @Transactional 注解属性
propagation
设置错误- @Transactional 注解属性
rollbackFor
设置错误- 同一个类中方法调用,导致 @Transactional 失效
- 异常被
catch
捕获,导致 @Transactional 失效
正确的拆分方法应该使用下面两种:
方法一
可以将方法放入另一个类中,如新增 Manager 层,通过 Spring 注入,这样符合了在对象之间调用的条件。
@Service
public class OrderService {
@Autowired
private OrderManager orderManager;
public void createOrder(OrderCreateDTO createDTO) {
query();
validate();
orderManager.saveData(createDTO);
}
}
@Service
public class OrderManager {
@Autowired
private OrderDao orderDao;
@Transactional(rollbackFor = Throwable.class)
public void saveData(OrderCreateDTO createDTO) {
orderDao.saveData(createDTO);
}
}
方法二
启动类添加 @EnableAspectJAutoProxy(exposeProxy = true)
注解,方法内使用 AopContext.currentProxy()
获得代理类,使用事务。
// SpringBootApplication.java
@SpringBootApplication
@EnableAspectJAutoProxy(exposeProxy = true)
public class SpringBootApplication {
}
// OrderService.java
public void createOrder(OrderCreateDTO createDTO) {
OrderService orderService = (OrderService)AopContext.currentProxy();
orderService.saveData(createDTO);
}
四. 小结
使用 @Transactional
注解在开发时确实很方便,但是稍微不注意就可能出现长事务问题。所以对于复杂业务逻辑,我这里更建议使用编程式事务来管理事务。当然,如果你非要用 @Transactional
,可以根据上文提到的两种方案进行方法拆分。