mysql连接耗尽_连接池耗尽了!!!

连接池耗尽了!!!

问题出现

早上微信朋友咨询一个压测问题：应用程序开启事务后，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、分布式事务