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

前言

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

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

大事务引起的问题

在分享解决办法以前，先看看系统中若是出现大事务可能会引起哪些问题面试

从上图能够看出若是系统中出现大事务时，问题还不小，因此咱们在实际项目开发中应该尽可能避免大事务的状况。若是咱们已有系统中存在大事务问题，该如何解决呢？redis

解决办法

少用@Transactional注解

你们在实际项目开发中，咱们在业务方法加上@Transactional注解开启事务功能，这是很是广泛的作法，它被称为声明式事务。spring

部分代码以下：sql

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

然而，我要说的第一条是：少用@Transactional注解。mongodb

为何？数据库

咱们知道 @Transactional注解是经过 spring的 aop起做用的，可是若是使用不当，事务功能可能会失效。若是恰巧你经验不足，这种问题不太好排查。至于事务哪些状况下会失效，能够参考我以前写的《 spring事务的这10种坑，你稍不注意可能就会踩中！！！》这篇文章。
@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();
   }

能够将queryData1和queryData2两个查询方法放在事务外执行，将真正须要事务执行的代码才放到事务中，好比：addData1和updateData2方法，这样就能有效的减小事务的粒度。

若是使用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种办法：

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

最后说一句

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