连接池耗尽了!!!

Posted 2021-04-06 IT技术圈子

连接池耗尽了!!!

问题出现

早上微信朋友咨询一个压测问题：应用程序开启事务后，QPS上不去.请求一起定位问题

问题定位

查看请求方法，结构如下：

@Transactional
public void longTransactionalFunction(Order bo) {
    //预处理对象
    OrderPred orderPred =pre(bo);
    //调用RPC处理订单相关
    callRPC(orderPred);
    try {
       //保存库
       orderDAO.save(orederPred);
    } catch (Exception e) {
       e.printStackTrace();
    }
}

可以很清晰的看到,在本地事务中调用了RPC方法。问题出现的地方已经很明显了，就是本地长事务占用了连接池的有效连接，导致后续调用挂起等待。自然QPS上不去。

解决方案

将RPC调用放到事务之外，调整后的代码如下：

public void saveOrder(Order bo){
    //预处理对象
    OrderPred orderPred =pre(bo);
    //调用RPC处理订单相关
    callRPC(orderPred);
    shortTransactionalFunction(orderPred);
}

@Transactional
public void shortTransactionalFunction(Order bo) {
    try {
       //保存库
       orderDAO.save(orederPred);
    } catch (Exception e) {
       e.printStackTrace();
    }
}

这样,开启事务的部分仅处理有效的保存订单的操作.有效的提高了QPS

思考点

阿里巴巴规范

【参考】 @Transactional 事务不要滥用。事务会影响数据库的 QPS，另外使用事务的地方需 要考虑各方面的回滚方案，包括缓存回滚、搜索引擎回滚、消息补偿、统计修正等。

可以看到阿里规范上已经告诫我们不要滥用本地的Transactional。那么什么是滥用了？我的理解就是不要随便在有事务的方法上注上@Transactional就完事了，需要认真去考虑哪些操作确实是需要事务控制的。特别是一些耗时的处理或则远程调用（远程调用无法靠本地事务控制）更需要全面评估。

关联点

1、数据库连接池 2、mysql事务 3、分布式事务