让人头痛的大事务问题到底要如何解决?

原创
2020/11/30 09:24
阅读数 376

前言

最近有个网友问了我一个问题:系统中大事务问题要如何处理?

正好前段时间我在公司处理过这个问题,我们当时由于项目初期时间比较紧张,为了快速完成业务功能,忽略了系统部分性能问题。项目顺利上线后,专门抽了一个迭代的时间去解决大事务问题,目前已经优化完成,并且顺利上线。现给大家总结了一下,我们当时使用的一些解决办法,以便大家被相同问题困扰时,可以参考一下。

大事务引发的问题

在分享解决办法之前,先看看系统中如果出现大事务可能会引发哪些问题

从上图可以看出如果系统中出现大事务时,问题还不小,所以我们在实际项目开发中应该尽量避免大事务的情况。如果我们已有系统中存在大事务问题,该如何解决呢?

解决办法

少用@Transactional注解

大家在实际项目开发中,我们在业务方法加上@Transactional注解开启事务功能,这是非常普遍的做法,它被称为声明式事务

部分代码如下:

   @Transactional(rollbackFor=Exception.class)
public void save(User user)
{
doSameThing...
}

然而,我要说的第一条是:少用@Transactional注解。

为什么?

  1. 我们知道 @Transactional注解是通过 springaop起作用的,但是如果使用不当,事务功能可能会失效。如果恰巧你经验不足,这种问题不太好排查。至于事务哪些情况下会失效,可以参考我之前写的《 spring事务的这10种坑,你稍不注意可能就会踩中!!!》这篇文章。
  2. @Transactional注解一般加在某个业务方法上,会导致整个业务方法都在同一个事务中,粒度太粗,不好控制事务范围,是出现大事务问题的最常见的原因。

那我们该怎么办呢?

可以使用编程式事务,在spring项目中使用TransactionTemplate类的对象,手动执行事务。

部分代码如下:

   
@Autowired
private TransactionTemplate transactionTemplate;

...

public void save(final User user) {
transactionTemplate.execute((status) => {
doSameThing...
return Boolean.TRUE;
})
}

从上面的代码中可以看出,使用TransactionTemplate编程式事务功能自己灵活控制事务的范围,是避免大事务问题的首选办法。

当然,我说少使用@Transactional注解开启事务,并不是说一定不能用它,如果项目中有些业务逻辑比较简单,而且不经常变动,使用@Transactional注解开启事务开启事务也无妨,因为它更简单,开发效率更高,但是千万要小心事务失效的问题。

将查询(select)方法放到事务外

如果出现大事务,可以将查询(select)方法放到事务外,也是比较常用的做法,因为一般情况下这类方法是不需要事务的。

比如出现如下代码:

   @Transactional(rollbackFor=Exception.class)
public void save(User user)
{
queryData1();
queryData2();
addData1();
updateData2();
}

可以将queryData1queryData2两个查询方法放在事务外执行,将真正需要事务执行的代码才放到事务中,比如:addData1updateData2方法,这样就能有效的减少事务的粒度。

如果使用TransactionTemplate编程式事务这里就非常好修改。

   
@Autowired
private TransactionTemplate transactionTemplate;

...

public void save(final User user) {
queryData1();
queryData2();
transactionTemplate.execute((status) => {
addData1();
updateData2();
return Boolean.TRUE;
})
}

但是如果你实在还是想用@Transactional注解,该怎么拆分呢?

    public void save(User user) {
queryData1();
queryData2();
doSave();
}

@Transactional(rollbackFor=Exception.class)
public void doSave(User user)
{
addData1();
updateData2();
}

这个例子是非常经典的错误,这种直接方法调用的做法事务不会生效,给正在坑中的朋友提个醒。因为@Transactional注解的声明式事务是通过spring aop起作用的,而spring aop需要生成代理对象,直接方法调用使用的还是原始对象,所以事务不会生效。

有没有办法解决这个问题呢?

1.新加一个Service方法

这个方法非常简单,只需要新加一个Service方法,把@Transactional注解加到新Service方法上,把需要事务执行的代码移到新方法中。具体代码如下:

  @Servcie
public class ServiceA {
@Autowired
prvate ServiceB serviceB;

public void save(User user) {
queryData1();
queryData2();
serviceB.doSave(user);
}
}

@Servcie
public class ServiceB {

@Transactional(rollbackFor=Exception.class)
public void doSave(User user)
{
addData1();
updateData2();
}

}

2.在该Service类中注入自己

如果不想再新加一个Service类,在该Service类中注入自己也是一种选择。具体代码如下:

  @Servcie
public class ServiceA {
@Autowired
prvate ServiceA serviceA;

public void save(User user) {
queryData1();
queryData2();
serviceA.doSave(user);
}

@Transactional(rollbackFor=Exception.class)
public void doSave(User user)
{
addData1();
updateData2();
}
}

可能有些人可能会有这样的疑问:这种做法会不会出现循环依赖问题?

其实spring ioc内部的三级缓存保证了它,不会出现循环依赖问题。如果你想进一步了解循环依赖问题,可以看看我之前文章《spring解决循环依赖为什么要用三级缓存?》。

3.在该Service类中使用AopContext.currentProxy()获取代理对象

上面的方法2确实可以解决问题,但是代码看起来并不直观,还可以通过在该Service类中使用AOPProxy获取代理对象,实现相同的功能。具体代码如下:

  @Servcie
public class ServiceA {

public void save(User user) {
queryData1();
queryData2();
((ServiceA)AopContext.currentProxy()).doSave(user);
}

@Transactional(rollbackFor=Exception.class)
public void doSave(User user)
{
addData1();
updateData2();
}
}

事务中避免远程调用

我们在接口中调用其他系统的接口是不能避免的,由于网络不稳定,这种远程调的响应时间可能比较长,如果远程调用的代码放在某个事物中,这个事物就可能是大事务。当然,远程调用不仅仅是指调用接口,还有包括:发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;
})
}

有些朋友可能会问,远程调用的代码不放在事务中如何保证数据一致性呢?这就需要建立:重试+补偿机制,达到数据最终一致性了。

事务中避免一次性处理太多数据

如果一个事务中需要处理的数据太多,也会造成大事务问题。比如为了操作方便,你可能会一次批量更新1000条数据,这样会导致大量数据锁等待,特别在高并发的系统中问题尤为明显。

解决办法是分页处理,1000条数据,分50页,一次只处理20条数据,这样可以大大减少大事务的出现。

非事务执行

在使用事务之前,我们都应该思考一下,是不是所有的数据库操作都需要在事务中执行?

   
@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();
}

当然大事务中要鉴别出哪些方法可以非事务执行,其实没那么容易,需要对整个业务梳理一遍,才能找出最合理的答案。

异步处理

还有一点也非常重要,是不是事务中的所有方法都需要同步执行?我们都知道,方法同步执行需要等待方法返回,如果一个事务中同步执行的方法太多了,势必会造成等待时间过长,出现大事务问题。

看看下面这个列子:

   
@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种办法:

  1. 少用@Transactional注解
  2. 将查询(select)方法放到事务外
  3. 事务中避免远程调用
  4. 事务中避免一次性处理太多数据
  5. 非事务执行
  6. 异步处理

最后说一句

如果这篇文章对您有所帮助,或者有所启发的话,帮忙扫描下发二维码关注一下,或者点赞、转发、在看。在公众号中回复:面试、代码神器、开发手册、时间管理有超赞的粉丝福利,另外回复:加群,可以跟很多大厂的前辈交流和学习。

推荐阅读:

mysql的这几个坑你踩过没?真是防不胜防
线程池最佳线程数量到底要如何配置?
这8种保证线程安全的技术你都知道吗?
springboot面试杀手锏-自动配置原理
11张图让你彻底明白jdk1.7 hashmap的死循环是如何产生的
硬核 | 使用spring cache让我的接口性能瞬间提升了100倍
实战|如何消除又臭又长的if...else判断更优雅的编程?
老司机手把手教你编写自己的springboot starter
面试前看了这篇spring事务的文章,让我多要了2k的工资


本文分享自微信公众号 - 苏三说技术(gh_9f551dfec941)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
打赏
0
0 收藏
分享
加载中
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部