系统性能优化之编程式事务

一、示例代码

用户下单后要进行发货，伪代码如下：

    /**
     * 订单发货
     * @param orderId
     */
    @Transactional(rollbackFor = Exception.class)
    public void sendOrder(String orderId){
        // 1、查询订单
        // 2、用RestTemplate调用远程物流接口发货 ---- 需要耗时2秒钟
        // 3、更新订单状态
    }

正常情况下，我们都会常规性地在接口方法上加上事务注解@Transactional。但有一天，高峰时期系统突然无法访问，出现假死。当然系统不是真的宕机，而是所有和数据库有关的连接都被阻塞，连接池已经无法获取连接了。

二、原因分析

通常情况下，大部人的解决办法是调整数据库连接池大小，认为是高峰时期系统设置的连接池数量大小，不足以支撑早高峰的连接数量导致的，如将数据库连接池的数量调整到了200甚至更大。

即使将配置调整成了200，服务重启也恢复了正常，但这是指标不治本的一种处理方式，只有找到了真正的原因才能从根本上解决这个问题。

通过仔细分析后我们可以发现，在sendOrder加上@Transactional 事务注解后，请求刚进入sendOrder方法时，就会从数据库连接获取一个连接。可是此时，程序并没有和数据库相关的操作，如果此时代码在步骤2远程调用接口时出现io或者网络阻塞，就会导致事务无法提交，连接也就会一直被该请求占用，而再大的连接池也会被耗费殆尽，从而造成系统崩溃。

三、错误的解决办法

3.1 将需要加事务的代码块抽取成子方法并加事务注解

首先分析有没有需要使用事务的必要。在步骤3中，数据操作，看代码后发现只有对一张表的操作，同时和其它操作没有相关性。而且本身属于最后一个步骤。所以在此代码中完全没有必要使用，删除注解即可。

当然如果步骤3操作数据库是多表操作，具有强相关性，数据一致，我们可以这样做，将步骤3无关的步骤分开，变成两个方法，那么在步骤2处发生阻塞也不会影响到数据库连接。

    /**
     * 订单发货
     * @param orderId
     */
    public void sendOrder(String orderId){
        // 1、查询订单
        // 2、用RestTemplate调用远程物流接口发货 ---- 需要耗时5秒钟
        this.updateOrder();
    }

    @Transactional(rollbackFor = Exception.class)
    public void updateOrder(){
        // 3、更新订单状态 
    }

这种方式看上去似乎没什么毛病，但这种方式updateOrder方法上的@Transactional事务注解是无效的，这就是Spring事务注解失效的问题。

事务注解为什么会失效呢，我们需要研究下@Transactional注解的原理：

Spring之所以可以对开启@Transactional的方法进行事务管理，是因为Spring为当前类生成了一个代理类，然后在执行相关方法时，会判断这个方法有没有@Transactional注解，如果有的话，则会开启一个事务。

sendOrder()方法是被代理类执行的，但该方法上没有写事务注解，所以不会执行事务。另外updateOrder()方法是被当前类this调用的，而不是Spring的动态代理类，所以updateOrder()方法上即使写了事务注解，但也不会执行事务，从而导致@Transactional失败。

可参考：

Spring事务注解@Transactional失效和切面失效问题

Spring中解决事务以及异步注解失效

四、正确的解决办法

4.1 编程式事务

通过代码分析，只有步骤3才需要进行事务控制（如果步骤3有多表操作），步骤1和步骤2都不需要事务控制，因此我们可以通过编程式事务来精确为步骤3加上事务。

   private TransactionTemplate template;

    /**
     * 订单发货
     * @param orderId
     */
    public void sendOrder(String orderId){
        // 1、查询订单
        // 2、用RestTemplate调用远程物流接口发货 ---- 需要耗时5秒钟

        // 编程式事务，手动控制哪些代码块要加事务控制
        template.execute(new TransactionCallback<Object>() {
            @Override
            public Object doInTransaction(TransactionStatus transactionStatus) {
                // 3、更新订单状态

                return null;
            }
        });

    }

推荐阅读：一次线上故障：数据库连接池泄露后的思考

最后编辑于：2020.07.25 17:14:47