让人头痛的大事务问题到底要如何解决?
所谓的大事务就是耗时比较长的事务。
Spring有两种方式实现事务,分别是编程式和声明式两种。
不手动开启事务,mysql 默认自动提交事务,一条语句执行完自动提交。
一、大事务产生的原因
- 操作的数据比较多
- 调用了 rpc 方法
- 有其他非 DB 的耗时操作
- 大量的锁竞争
- 执行了比较耗时的计算
二、大事务造成的影响
- 并发情况下,数据库连接池容易被撑爆
- 锁定太多的数据,造成大量的阻塞和锁超时
- 执行时间长,容易造成主从延迟
- 回滚所需要的时间比较长
- undo log日志膨胀,不仅增加了存储的空间,而且可能降低查询的性能
最主要的影响数据库连接池容易被撑爆,导致大量线程等待,造成请求无响应或请求超时。
三、大事务优化方案
1、使用编程式事务
在实际项目开发中,有多个写请求就需要用到事务,我们在业务方法加上@Transactional
注解开启事务功能,这是非常普遍的做法,它被称为声明式事务
。
部分代码如下:
@Transactional
public void save(User user) {
//doSameThing...
}
然而,我要说的第一条是:少用@Transactional注解。
为什么?
- 我们知道@Transactional注解是通过spring的aop起作用的,但是如果使用不当,事务功能可能会失效。如果恰巧你经验不足,这种问题不太好排查。
- @Transactional 注解一般加在某个业务方法上,会导致整个业务方法都在同一个事务中,粒度太粗,不好控制事务范围,是出现大事务问题的最常见的原因。
那我们该怎么办呢?
可以使用编程式事务
,在spring项目中使用TransactionTemplate
类的对象,手动执行事务。
部分代码如下:
@Autowired
private TransactionTemplate transactionTemplate;
<span class="hljs-keyword">public</span> <span class="hljs-keyword">void</span> <span class="hljs-title function_">save</span><span class="hljs-params">()</span> {
transactionTemplate.execute((status) -> {
userMapper.insertSelective(user);
goodsMapper.insert(goods);
<span class="hljs-keyword">return</span> Boolean.TRUE;
});
}
如果是在说在编程式事务事务中,需要回滚,我们可以这样操作
public void save() {
transactionTemplate.execute((status) -> {
userMapper.insertSelective(user);
//直接抛异常,就会自动回滚
Assert.error("业务逻辑没通过,直接报错");
goodsMapper.insert(goods);
return Boolean.TRUE;
});
}
从上面的代码中可以看出,使用TransactionTemplate的编程式事务功能自己灵活控制事务的范围,是避免大事务问题的首选办法。
当然,我说少使用@Transactional
注解开启事务,并不是说一定不能用它,如果项目中有些业务逻辑比较简单,而且不经常变动,使用@Transactional注解开启事务开启事务
也无妨,因为它更简单,开发效率更高,但是千万要小心事务失效的问题。
2、将查询(select)方法放到事务外
如果出现大事务,可以将查询(select)方法放到事务外,也是比较常用的做法,因为一般情况下这类方法是不需要事务的。
比如出现如下代码:
@Transactional(rollbackFor=Exception.class)
public void save() {
queryData1();
queryData2();
saveData1();
updateData2();
}
可以将 queryData1 和 queryData2 两个查询方法放在事务外执行,将真正需要事务执行的代码才放到事务中,比如:saveData1 和updateData2 方法,这样就能有效的
减少事务的粒度。
如果使用TransactionTemplate
的 编程式事务 这里就非常好修改。
public void save() {
queryData1();
queryData2();
transactionTemplate.execute((status) -> {
saveData1();
updateData2();
return Boolean.TRUE;
})
}
但是如果你实在还是想用@Transactional注解,该怎么拆分呢?
public void save() {
queryData1();
queryData2();
doSave();
}
<span class="hljs-meta">@Transactional(rollbackFor = Exception.class)</span>
<span class="hljs-keyword">public</span> <span class="hljs-keyword">void</span> <span class="hljs-title function_">doSave</span><span class="hljs-params">()</span> {
saveData1();
updateData2();
}
这个例子是非常经典的错误,这种直接方法调用的做法事务不会生效,给正在坑中的朋友提个醒。因为@Transactional
注解的声明式事务是通过spring aop
起作用的,
而spring aop 需要生成代理对象,直接方法调用使用的还是原始对象,所以事务不会生效。
有没有办法解决这个问题呢?
1、新加一个Service方法
这个方法非常简单,只需要新加一个Service方法,把 @Transactional 注解加到新Service方法上,把需要事务执行的代码移到新方法中。
具体代码如下:
@Servcie
publicclass ServiceA {
@Autowired
prvate ServiceB serviceB;
<span class="hljs-keyword">public</span> <span class="hljs-keyword">void</span> <span class="hljs-title function_">save</span><span class="hljs-params">()</span> {
queryData1();
queryData2();
serviceB.doSave();
}
}
@Servcie
publicclass ServiceB {
<span class="hljs-meta">@Transactional(rollbackFor=Exception.class)</span>
<span class="hljs-keyword">public</span> <span class="hljs-keyword">void</span> <span class="hljs-title function_">doSave</span><span class="hljs-params">()</span> {
saveData1();
updateData2();
}
}
2、在该Service类中注入自己
如果不想再新加一个Service类,在该Service类中注入自己也是一种选择。
具体代码如下:
@Servcie
public class ServiceA {
@Autowired
prvate ServiceA serviceA;
<span class="hljs-keyword">public</span> <span class="hljs-keyword">void</span> <span class="hljs-title function_">save</span><span class="hljs-params">()</span> {
queryData1();
queryData2();
serviceA.doSave();
}
<span class="hljs-meta">@Transactional(rollbackFor = Exception.class)</span>
<span class="hljs-keyword">public</span> <span class="hljs-keyword">void</span> <span class="hljs-title function_">doSave</span><span class="hljs-params">()</span> {
saveData1();
updateData2();
}
}
可能有些人可能会有这样的疑问:这种做法会不会出现循环依赖问题?
其实spring ioc内部的三级缓存保证了它,不会出现循环依赖问题。
3、在该Service类中使用AopContext.currentProxy()获取代理对象
上面的方法2确实可以解决问题,但是代码看起来并不直观,还可以通过在该Service类中使用AOPProxy获取代理对象,实现相同的功能。具体代码如下:
@Servcie
publicclass ServiceA {
<span class="hljs-keyword">public</span> <span class="hljs-keyword">void</span> <span class="hljs-title function_">save</span><span class="hljs-params">()</span> {
queryData1();
queryData2();
((ServiceA)AopContext.currentProxy()).doSave();
}
<span class="hljs-meta">@Transactional(rollbackFor=Exception.class)</span>
<span class="hljs-keyword">public</span> <span class="hljs-keyword">void</span> <span class="hljs-title function_">doSave</span><span class="hljs-params">()</span> {
saveData1();
updateData2();
}
}
3、事务中避免远程调用
我们在接口中调用其他系统的接口是不能避免的,由于网络不稳定,这种远程调的响应时间可能比较长,如果远程调用的代码放在某个事物中,这个事物就可能是大事务。
当然,远程调用不仅仅是指调用接口,还有包括:发MQ消息,或者连接redis、mongodb保存数据等。
@Transactional(rollbackFor=Exception.class)
public void save(User user) {
callRemoteApi();
addData1();
}
远程调用的代码可能耗时较长,切记一定要放在事务之外。
@Autowired
private TransactionTemplate transactionTemplate;
public void save(final User user) {
callRemoteApi();
transactionTemplate.execute((status) => {
addData1();
return Boolean.TRUE;
})
}
有些朋友可能会问,远程调用的代码不放在事务中如何保证数据一致性呢?这就需要建立:重试
+补偿机制
,达到数据最终一致性
了。
4、事务中避免一次性处理太多数据
如果一个事务中处理的数据太多,也会造成大事务问题。比如为了操作方便,你可能会一次批量更新1000条数据,这样会导致大量数据锁等待,在高并发的系统中问题尤为明显。
解决办法是分页处理,1000条数据,分20页,前端每次请求只处理当页面50条数据,这样可以大大减少大事务的出现。
5、是否可以通过非事务方式执行
在使用事务之前,我们都应该思考一下,是不是所有的数据库操作都需要在事务中执行?
@Autowired
private TransactionTemplate transactionTemplate;
...
public void save(final User user) {
transactionTemplate.execute((status) => {
addData();
addLog();
updateCount();
return Boolean.TRUE;
})
}
上面的例子中,其实addLog增加操作日志方法 和 updateCount更新统计数量方法,是可以不在事务中执行的,因为操作日志和统计数量这种业务允许少量数据不一致的情况。
@Autowired
private TransactionTemplate transactionTemplate;
...
public void save(final User user) {
transactionTemplate.execute((status) => {
addData();
return Boolean.TRUE;
})
addLog();
updateCount();
}
当然大事务中要鉴别出哪些方法可以非事务执行,其实没那么容易,需要对整个业务梳理一遍,才能找出最合理的答案。
6、是否可以通过异步处理?
还有一点也非常重要,是不是事务中的所有方法都需要同步执行?
我们都知道,方法同步执行需要等待方法返回,如果一个事务中同步执行的方法太多了,势必会造成等待时间过长,出现大事务问题。
看看下面这个列子:
@Autowired
private TransactionTemplate transactionTemplate;
...
public void save(final User user) {
transactionTemplate.execute((status) => {
order();
delivery();
return Boolean.TRUE;
})
}
order方法用于下单,delivery方法用于发货,是不是下单后就一定要马上发货呢?
答案是否定的。
这里发货功能其实可以走mq异步处理逻辑。
@Autowired
private TransactionTemplate transactionTemplate;
...
public void save(final User user) {
transactionTemplate.execute((status) => {
order();
return Boolean.TRUE;
})
sendMq();
}
总结
本人从网友的一个问题出发,结合自己实际的工作经验分享了处理大事务的6种办法:
- 少用@Transactional注解
- 将查询(select)方法放到事务外
- 事务中避免远程调用
- 事务中避免一次性处理太多数据
- 非事务执行
- 异步处理
参考
1、让人头痛的大事务问题到底要如何解决?(非常感谢,这篇博客主要基于本篇)
2、注意Spring事务这一点,避免出现大事务
3、spring 大事务