Spring大事务到底如何优化？

本文主要是介绍Spring大事务到底如何优化？，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

所谓的大事务就是耗时比较长的事务。

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;

    public void save() {
        transactionTemplate.execute((status) -> {
            userMapper.insertSelective(user);
            goodsMapper.insert(goods);
            return 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();
    }

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

这个例子是非常经典的错误，这种直接方法调用的做法事务不会生效，给正在坑中的朋友提个醒。因为@Transactional注解的声明式事务是通过spring aop起作用的，

而spring aop 需要生成代理对象，直接方法调用使用的还是原始对象，所以事务不会生效。

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

1、新加一个Service方法

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

具体代码如下：

@Servcie
  publicclass ServiceA {
     @Autowired
     prvate ServiceB serviceB;
  
     public void save() {
           queryData1();
           queryData2();
           serviceB.doSave();
     }
   }
   
   @Servcie
   publicclass ServiceB {
   
      @Transactional(rollbackFor=Exception.class)
      public void doSave() {
         saveData1();
         updateData2();
      }
   
   }

2、在该Service类中注入自己

如果不想再新加一个Service类，在该Service类中注入自己也是一种选择。

具体代码如下：

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

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

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

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

其实spring ioc内部的三级缓存保证了它，不会出现循环依赖问题。

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

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

@Servcie
  publicclass ServiceA {
  
     public void save() {
           queryData1();
           queryData2();
           ((ServiceA)AopContext.currentProxy()).doSave();
     }
     
     @Transactional(rollbackFor=Exception.class)
     public void doSave() {
         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 大事务

这篇关于Spring大事务到底如何优化？的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！

Java教程