如何解决大事务问题

àì夳堔傛蜴生んèń 2024-03-22 18:54 19阅读 0赞

## 大事务带来的问题 ##

![在这里插入图片描述][c23a4d6c5582465ab9e04bf0a99cb49a.png]

## 解决方案 ##

### 少用@Transactional注解，使用编程式事务TransactionTemplate ###

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

部分代码如下：

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

为什么少用@Transactional注解。

我们知道@Transactional注解是通过spring的aop起作用的，但是如果使用不当，事务功能可能会失效。如果恰巧你经验不足，这种问题不太好排查。至于事务哪些情况下会失效，可以参考  
[spring事务不生效的多种场景][spring]  
@Transactional注解一般加在某个业务方法上，会导致整个业务方法都在同一个事务中，粒度太粗，不好控制事务范围，是出现大事务问题的最常见的原因。  
那我们该怎么办呢？

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

部分代码如下：

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

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

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

### 梳理不需要事务执行的方法 ###

#### 将查询(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
      publicclass ServiceA {
        
         @Autowired
         prvate ServiceB serviceB;
      
         public void save(User user) {
        
               queryData1();
               queryData2();
               serviceB.doSave(user);
         }
       }
       
       @Servcie
       publicclass ServiceB {
        
       
          @Transactional(rollbackFor=Exception.class)
          public void doSave(User user) {
        
             addData1();
             updateData2();
          }
       
       }

2.在该Service类中注入自己

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

@Servcie
      publicclass 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内部的三级缓存保证了它，不会出现循环依赖问题。

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

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

@Servcie
      publicclass ServiceA {
        
      
         public void save(User user) {
        
               queryData1();
               queryData2();
               ((ServiceA)AopContext.currentProxy()).doSave(user);
         }
         
         @Transactional(rollbackFor=Exception.class)
         public void doSave(User user) {
        
             addData1();
             updateData2();
          }
       }

#### 非核心方法放到事务外 ####

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

@Autowired
       private TransactionTemplate transactionTemplate;
       
       ...
       
       public void save(final User user) {
        
             transactionTemplate.execute((status) => {
        
                addData();
                addLog();
                updateCount();
                return Boolean.TRUE;
             })
       }

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

#### 通过MQ异步处理 ####

是不是事务中的所有方法都需要同步执行？我们都知道，方法同步执行需要等待方法返回，如果一个事务中同步执行的方法太多了，势必会造成等待时间过长，出现大事务问题。上面addLog增加操作日志方法 和 updateCount更新统计数量方法，我们可以通过MQ异步处理

@Autowired
       private TransactionTemplate transactionTemplate;
       
       ...
       
       public void save(final User user) {
        
             transactionTemplate.execute((status) => {
        
                addData();
                return Boolean.TRUE;
             })
             sendMq();
       }

### 事务中避免远程调用 ###

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

[c23a4d6c5582465ab9e04bf0a99cb49a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/322862cd03474e57900cd49e6092285d.png
[spring]: https://blog.csdn.net/qq798280904/article/details/130728756