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

本文转载自微信公众号「苏三说技术」，作者因为热爱所以坚持ing。转载本文请联系苏三说技术公众号。   

新平ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景，ssl证书未来市场广阔！成为创新互联公司的ssl证书销售渠道，可以享受市场价格4-6折优惠！如果有意向欢迎电话联系或者加微信：028-86922220（备注：SSL证书合作）期待与您的合作！

前言

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

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

大事务引发的问题

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

 

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

解决办法

少用@Transactional注解

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

部分代码如下：

 
 
 
 
    
  
  
  
  
  1. @Transactional(rollbackFor=Exception.class) 
    2. 
  
  
  
  
  2.   public void save(User user) { 
    3. 
  
  
  
  
  3.         doSameThing... 
    4. 
  
  
  
  
  4.   } 
    5.

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

为什么?

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

那我们该怎么办呢?

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

部分代码如下：

 
 
 
 
    
  
  
  
  
  1. @Autowired 
    2. 
  
  
  
  
  2.    private TransactionTemplate transactionTemplate; 
    3. 
  
  
  
  
  3.     
    4. 
  
  
  
  
  4.    ... 
    5. 
  
  
  
  
  5.     
    6. 
  
  
  
  
  6.    public void save(final User user) { 
    7. 
  
  
  
  
  7.          transactionTemplate.execute((status) => { 
    8. 
  
  
  
  
  8.             doSameThing... 
    9. 
  
  
  
  
  9.             return Boolean.TRUE; 
    10. 
  
  
  
  
  10.          }) 
    11. 
  
  
  
  
  11.    } 
    12.

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

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

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

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

比如出现如下代码：

 
 
 
 
    
  
  
  
  
  1. @Transactional(rollbackFor=Exception.class) 
    2. 
  
  
  
  
  2.    public void save(User user) { 
    3. 
  
  
  
  
  3.          queryData1(); 
    4. 
  
  
  
  
  4.          queryData2(); 
    5. 
  
  
  
  
  5.          addData1(); 
    6. 
  
  
  
  
  6.          updateData2(); 
    7. 
  
  
  
  
  7.    } 
    8.

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

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

 
 
 
 
    
  
  
  
  
  1. @Autowired 
    2. 
  
  
  
  
  2.    private TransactionTemplate transactionTemplate; 
    3. 
  
  
  
  
  3.     
    4. 
  
  
  
  
  4.    ... 
    5. 
  
  
  
  
  5.     
    6. 
  
  
  
  
  6.    public void save(final User user) { 
    7. 
  
  
  
  
  7.          queryData1(); 
    8. 
  
  
  
  
  8.          queryData2(); 
    9. 
  
  
  
  
  9.          transactionTemplate.execute((status) => { 
    10. 
  
  
  
  
  10.             addData1(); 
    11. 
  
  
  
  
  11.             updateData2(); 
    12. 
  
  
  
  
  12.             return Boolean.TRUE; 
    13. 
  
  
  
  
  13.          }) 
    14. 
  
  
  
  
  14.    } 
    15.

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

 
 
 
 
    
  
  
  
  
  1. public void save(User user) { 
    2. 
  
  
  
  
  2.          queryData1(); 
    3. 
  
  
  
  
  3.          queryData2(); 
    4. 
  
  
  
  
  4.          doSave(); 
    5. 
  
  
  
  
  5.     } 
    6. 
  
  
  
  
  6.     
    7. 
  
  
  
  
  7.     @Transactional(rollbackFor=Exception.class) 
    8. 
  
  
  
  
  8.     public void doSave(User user) { 
    9. 
  
  
  
  
  9.        addData1(); 
    10. 
  
  
  
  
  10.        updateData2(); 
    11. 
  
  
  
  
  11.     } 
    12.

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

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

1.新加一个Service方法

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

 
 
 
 
    
  
  
  
  
  1. @Servcie 
    2. 
  
  
  
  
  2.   public class ServiceA { 
    3. 
  
  
  
  
  3.      @Autowired 
    4. 
  
  
  
  
  4.      prvate ServiceB serviceB; 
    5. 
  
  
  
  
  5.    
    6. 
  
  
  
  
  6.      public void save(User user) { 
    7. 
  
  
  
  
  7.            queryData1(); 
    8. 
  
  
  
  
  8.            queryData2(); 
    9. 
  
  
  
  
  9.            serviceB.doSave(user); 
    10. 
  
  
  
  
  10.      } 
    11. 
  
  
  
  
  11.    } 
    12. 
  
  
  
  
  12.     
    13. 
  
  
  
  
  13.    @Servcie 
    14. 
  
  
  
  
  14.    public class ServiceB { 
    15. 
  
  
  
  
  15.     
    16. 
  
  
  
  
  16.       @Transactional(rollbackFor=Exception.class) 
    17. 
  
  
  
  
  17.       public void doSave(User user) { 
    18. 
  
  
  
  
  18.          addData1(); 
    19. 
  
  
  
  
  19.          updateData2(); 
    20. 
  
  
  
  
  20.       } 
    21. 
  
  
  
  
  21.     
    22. 
  
  
  
  
  22.    } 
    23.

2.在该Service类中注入自己

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

 
 
 
 
    
  
  
  
  
  1. @Servcie 
    2. 
  
  
  
  
  2.   public class ServiceA { 
    3. 
  
  
  
  
  3.      @Autowired 
    4. 
  
  
  
  
  4.      prvate ServiceA serviceA; 
    5. 
  
  
  
  
  5.    
    6. 
  
  
  
  
  6.      public void save(User user) { 
    7. 
  
  
  
  
  7.            queryData1(); 
    8. 
  
  
  
  
  8.            queryData2(); 
    9. 
  
  
  
  
  9.            serviceA.doSave(user); 
    10. 
  
  
  
  
  10.      } 
    11. 
  
  
  
  
  11.       
    12. 
  
  
  
  
  12.      @Transactional(rollbackFor=Exception.class) 
    13. 
  
  
  
  
  13.      public void doSave(User user) { 
    14. 
  
  
  
  
  14.          addData1(); 
    15. 
  
  
  
  
  15.          updateData2(); 
    16. 
  
  
  
  
  16.       } 
    17. 
  
  
  
  
  17.    } 
    18.

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

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

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

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

 
 
 
 
    
  
  
  
  
  1. @Servcie 
    2. 
  
  
  
  
  2.   public class ServiceA { 
    3. 
  
  
  
  
  3.    
    4. 
  
  
  
  
  4.      public void save(User user) { 
    5. 
  
  
  
  
  5.            queryData1(); 
    6. 
  
  
  
  
  6.            queryData2(); 
    7. 
  
  
  
  
  7.            ((ServiceA)AopContext.currentProxy()).doSave(user); 
    8. 
  
  
  
  
  8.      } 
    9. 
  
  
  
  
  9.       
    10. 
  
  
  
  
  10.      @Transactional(rollbackFor=Exception.class) 
    11. 
  
  
  
  
  11.      public void doSave(User user) { 
    12. 
  
  
  
  
  12.          addData1(); 
    13. 
  
  
  
  
  13.          updateData2(); 
    14. 
  
  
  
  
  14.       } 
    15. 
  
  
  
  
  15.    } 
    16.

事务中避免远程调用

我们在接口中调用其他系统的接口是不能避免的，由于网络不稳定，这种远程调的响应时间可能比较长，如果远程调用的代码放在某个事物中，这个事物就可能是大事务。当然，远程调用不仅仅是指调用接口，还有包括：发MQ消息，或者连接redis、mongodb保存数据等。

 
 
 
 
    
  
  
  
  
  1. @Transactional(rollbackFor=Exception.class) 
    2. 
  
  
  
  
  2.    public void save(User user) { 
    3. 
  
  
  
  
  3.          callRemoteApi(); 
    4. 
  
  
  
  
  4.          addData1(); 
    5. 
  
  
  
  
  5.    } 
    6.

远程调用的代码可能耗时较长，切记一定要放在事务之外。

 
 
 
 
    
  
  
  
  
  1. @Autowired 
    2. 
  
  
  
  
  2.    private TransactionTemplate transactionTemplate; 
    3. 
  
  
  
  
  3.     
    4. 
  
  
  
  
  4.    ... 
    5. 
  
  
  
  
  5.     
    6. 
  
  
  
  
  6.    public void save(final User user) { 
    7. 
  
  
  
  
  7.          callRemoteApi(); 
    8. 
  
  
  
  
  8.          transactionTemplate.execute((status) => { 
    9. 
  
  
  
  
  9.             addData1(); 
    10. 
  
  
  
  
  10.             return Boolean.TRUE; 
    11. 
  
  
  
  
  11.          }) 
    12. 
  
  
  
  
  12.    } 
    13.

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

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

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

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

非事务执行

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

 
 
 
 
    
  
  
  
  
  1. @Autowired 
    2. 
  
  
  
  
  2.    private TransactionTemplate transactionTemplate; 
    3. 
  
  
  
  
  3.     
    4. 
  
  
  
  
  4.    ... 
    5. 
  
  
  
  
  5.     
    6. 
  
  
  
  
  6.    public void save(final User user) { 
    7. 
  
  
  
  
  7.          transactionTemplate.execute((status) => { 
    8. 
  
  
  
  
  8.             addData(); 
    9. 
  
  
  
  
  9.             addLog(); 
    10. 
  
  
  
  
  10.             updateCount(); 
    11. 
  
  
  
  
  11.             return Boolean.TRUE; 
    12. 
  
  
  
  
  12.          }) 
    13. 
  
  
  
  
  13.    } 
    14.

上面的例子中，其实addLog增加操作日志方法 和 updateCount更新统计数量方法，是可以不在事务中执行的，因为操作日志和统计数量这种业务允许少量数据不一致的情况。

 
 
 
 
    
  
  
  
  
  1. @Autowired 
    2. 
  
  
  
  
  2.    private TransactionTemplate transactionTemplate; 
    3. 
  
  
  
  
  3.     
    4. 
  
  
  
  
  4.    ... 
    5. 
  
  
  
  
  5.     
    6. 
  
  
  
  
  6.    public void save(final User user) { 
    7. 
  
  
  
  
  7.          transactionTemplate.execute((status) => { 
    8. 
  
  
  
  
  8.             addData();            
    9. 
  
  
  
  
  9.             return Boolean.TRUE; 
    10. 
  
  
  
  
  10.          }) 
    11. 
  
  
  
  
  11.          addLog(); 
    12. 
  
  
  
  
  12.          updateCount(); 
    13. 
  
  
  
  
  13.    } 
    14.

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

异步处理

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

看看下面这个列子：

 
 
 
 
    
  
  
  
  
  1. @Autowired 
    2. 
  
  
  
  
  2.    private TransactionTemplate transactionTemplate; 
    3. 
  
  
  
  
  3.     
    4. 
  
  
  
  
  4.    ... 
    5. 
  
  
  
  
  5.     
    6. 
  
  
  
  
  6.    public void save(final User user) { 
    7. 
  
  
  
  
  7.          transactionTemplate.execute((status) => { 
    8. 
  
  
  
  
  8.             order(); 
    9. 
  
  
  
  
  9.             delivery(); 
    10. 
  
  
  
  
  10.             return Boolean.TRUE; 
    11. 
  
  
  
  
  11.          }) 
    12. 
  
  
  
  
  12.    } 
    13.

order方法用于下单，delivery方法用于发货，是不是下单后就一定要马上发货呢?

答案是否定的。

这里发货功能其实可以走mq异步处理逻辑。

 
 
 
 
    
  
  
  
  
  1. @Autowired 
    2. 
  
  
  
  
  2.    private TransactionTemplate transactionTemplate; 
    3. 
  
  
  
  
  3.     
    4. 
  
  
  
  
  4.    ... 
    5. 
  
  
  
  
  5.     
    6. 
  
  
  
  
  6.    public void save(final User user) { 
    7. 
  
  
  
  
  7.          transactionTemplate.execute((status) => { 
    8. 
  
  
  
  
  8.             order(); 
    9. 
  
  
  
  
  9.             return Boolean.TRUE; 
    10. 
  
  
  
  
  10.          }) 
    11. 
  
  
  
  
  11.          sendMq(); 
    12. 
  
  
  
  
  12.    } 
    13.

总结

本人从网友的一个问题出发，结合自己实际的工作经验分享了处理大事务的6种办法：

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

新闻标题：让人头痛的大事务问题到底要如何解决？
网站地址：http://www.stwzsj.com/qtweb/news3/13203.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联

猜你还喜欢下面的内容

电子商务知识

各行业网站

广安网站设计　　 　网络营销推广　　 　成都温江机房　　 　网站开发　　 　电信机房托管　　 　成都APP定制开发　　 　腾讯云免备案主机　　 　自适应网站　　 　成都广告制作　　 　成都网站推广　　 　成都标志设计　　 　四川艾名斯　　 　成都免费建站　　 　云主机　　 　电子商务商城网站　　 　乐山中领科信　　 　seo优化　　 　网站营销推广　　 　雷运建站　　 　买友情链接