大事务问题【事务记录篇】

系统中大事务问题要如何处理？

大事务引发的问题

先看看系统中如果出现大事务可能会引发哪些问题

最常见的就是死锁和高并发下锁超时,其本质原因都是指在一组进程中的各个进程均占有不会释放的资源，但因互相申请被其他进程所站用不会释放的资源而处于的一种永久等待状态。大事务肯定会锁住资源,然后让其他需要锁住资源的事务一直等待，最后超时。另一种情况就是锁住需要的资源，然后再去申请其他资源的时候，结果这些资源被其他占用不释放那么就是死锁。

死锁的四个必要条件：

• 互斥条件(Mutual exclusion)：资源不能被共享，只能由一个进程使用。
• 请求与保持条件(Hold and wait)：已经得到资源的进程可以再次申请新的资源。
• 非剥夺条件(No pre-emption)：已经分配的资源不能从相应的进程中被强制地剥夺。
• 循环等待条件(Circular wait)：系统中若干进程组成环路，该环路中每个进程都在等待相邻进程正占用的资源。

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

解决办法

慎用/少用@Transactional注解

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

部分代码如下：

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

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

为什么说少用@Transactional注解？

1. 我们知道@Transactional注解是通过spring的aop起作用的，但是如果使用不当，事务功能可能会失效。如果恰巧你经验不足，这种问题不太好排查。
2. @Transactional注解一般加在某个业务方法上，会导致整个业务方法都在同一个事务中，粒度太粗，不好控制事务范围，是出现大事务问题的最常见的原因。

那我们该怎么办呢？

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

部分代码如下：

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

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

当然，我说少使用@Transactional注解开启事务，并不是说一定不能用它，如果项目中有些业务逻辑比较简单，而且不经常变动，使用@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需要生成代理对象，直接方法调用的其实是当前对象的原始方法,相当于内部调用,不会触发AOP的事务处理机制(触发事务机制需要使用springIOC容器封装好的代理对象)，所以事务不会生效。关于this的相关信息,请查看我的this的纪录篇。

    public void save(User user) {
         queryData1();
         queryData2();
         // 这里调用的源码是this.doSave();
         doSave();
    }
   
    @Transactional(rollbackFor=Exception.class)
    public void doSave(User user) {
       addData1();
       updateData2();
    }
}

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

1. 新加一个Service方法

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

@Servcie
  publicclass ServiceA {
    // 引入springIOC容器当中的代理对象
     @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 {
    // 引入springIOC容器当中的代理对象来调用doSave()方法
     @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();
           // 这里直接去获取代理类然后执行doSave()方法
           ((ServiceA)AopContext.currentProxy()).doSave(user);
     }
     
     @Transactional(rollbackFor=Exception.class)
     public void doSave(User user) {
         addData1();
         updateData2();
      }
   }
 }

事务中避免远程调用

现在的系统基本上都是避免不了调用其他第三方系统的API接口，由于网络不稳定或者被调用的系统本身的问题，这种远程调的响应时间可能会比较长，如果远程调用的代码放在某个事物中，这个事物就可能衍生为大事务。当然远程调用不仅仅是指调用接口，还有包括：发MQ消息，或者连接redis、mongodb保存数据等。

    // 这里的声明式事务就可能成为大事务
    @Transactional(rollbackFor=Exception.class)
   public void save(User user) {
        // 发送消息可能超时或者响应时间太长
         sendMsg();
         updateData();
   }

    // 远程调用的代码可能耗时较长，切记一定要放在事务之外。
   @Autowired
   private TransactionTemplate transactionTemplate;
   public void save(final User user) {
         sendMsg();
         // 编程式事务
         transactionTemplate.execute((status) => {
            updateData();
            return Boolean.TRUE;
         })
   }

有些朋友可能会问，远程调用的代码不放在事务中如何保证数据一致性呢？
那么我会反问,分布式服务的数据一致性也不是你单个服务的事务就能简简单单的处理的,都使用远程rpc调用了,那么肯定需要考虑数据一致性肯定
两种方式处理：

• 最终一致性：重试+补偿机制，达到数据最终一致性。
• 事务一致性: 分布式事务2PC,3PC

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

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

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

   @Autowired
   private TransactionTemplate transactionTemplate;
   
   ...
   
   public void save( List<User> userList) {
        // 根据配置切分集合,减少一次事务处理的数据,相对的降低了锁的颗粒度
        List<List<User>> list = this.splitList(useList);
        for (int i = 0; i < list.size(); i++) {
            List<User> dataList = list.get(i);
            transactionTemplate.execute((status) => {
                addData(dataList);
                addLog();
                updateCount();
                return Boolean.TRUE;
            })
        }
   }
   public List<List<User>> splitList(List<User> userList){
       ...
   }

非事务执行

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

   @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. 非同步业务或者非事务业务避免放入事务中执行,异步处理