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

一：初步排查

早上作为能效平台系统的使用高峰期，系统负载通常比其它时间段更大一些，某个时间段会有大量用户登录。当天系统开始有用户报障，发布系统线上无法构建发布，然后后续有用户不能登录系统，系统发生假死，当然系统不是真的宕机，而是所有和数据库有关的连接都被阻塞，随后查看日志发现有大量报错。

和数据库连接池相关：

Caused by: org.springframework.jdbc.CannotGetJdbcConnectionException: Failed to obtain JDBC Connection; nested exception is java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 30002ms.

可以看出上面的报错和数据库连接有关，大量超时。通过对线上debug日志的分析，也验证了数据库连接池被大量消耗。

[DEBUG] c.z.h.p.HikariPool: HikariPool-1 - Timeout failure stats (total=20, active=20, idle=0, waiting=13)

这是开始大量报错前的日志。我们可以看到此时HikariPool连接池已经无法获取连接了，active=20表示被获取正在被使用的数据库连接。waiting表示当前正在排队获取连接的请求数量。可以看出，已经有相当多的请求处于挂起状态。

所以当时我们的解决办法是调整数据库连接池大小，开始初步认为是，高峰时期，我们设置的连接池数量大小，不足以支撑早高峰的连接数量导致的。

jdbc.connection.timeout=30000jdbc.max.lifetime=1800000jdbc.maximum.poolsize=200jdbc.minimum.idle=10jdbc.idle.timeout=60000jdbc.readonly=false

我们将将数据库连接池的数量调整到了200。

二：事务

2.1事务滥用的后果

及时将配置调整成了200，服务重启也恢复了正常，但是我仍然认为系统存在连接泄露的风险，我试图从日志表现出的行为里寻找蛛丝马迹。我在访问日志看到每次在系统崩溃前，其实都有人在做构建，而且构建经常点击没反应，我当时添加的构建debug日志也显示了这一点。我开始怀疑是构建造成的连接泄露。

在这里我简单说下构建代码处的逻辑

• 用户触发构建

• 将job加入增量job缓存，用于更新job状态

• jenkinsClient调用jenkins的api，开始构建

• 将构建信息写入数据库（jobname，version）

我开始观察自己写的代码，可是看了多遍，我也发现不了这段代码和数据库连接有啥关系，大多数人包括当时自己来说，数据库连接的泄露，大多数情况应该是服务和数据库连接的过程中发生了阻塞，导致连接泄露。但是现在来看，很容易能发现问题所在，看当时的代码：

@Transactional(rollbackFor = Exception.class) public void build(BuildHistoryReq buildHistoryReq) { //1.封装操作 //2.调用jenkins Api //3.数据库更新写入 }

这就是当时的代码入口，当然代码处没有这么简单。可以看到我在方法入口就加上了Transactional注解，这里的意思其实就是发生错误，抛出异常时，数据库回滚。

问题就出现在了这里，当有用户点击构建时，请求刚进入build方法时，就会从数据库连接获取一个连接。可是此时，程序并没有和数据库相关的操作，如果此时代码在步骤1或者2处出现io或者网络阻塞，就会导致，事务无法提交，连接也就会一直被该请求占用。而再大的连接池也会被耗费殆尽。从而造成系统崩溃。

2.2事务注解的正确用法

通常情况下作为非业务部门，没有涉及到核心的业务，像支付，订单，库存相关的操作时，事务在可读层面并没有特别高的要求。通常也只涉及到，多表操作同时更新时，保证数据一致性，要么同时成功要么同时失败。而使用

@Transactional(rollbackFor = Exception.class)

足以。

而上述代码该如何改进呢？？

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

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

public void build(BuildHistoryReq buildHistoryReq) { //1.封装操作 //2.调用jenkins Api update**(XX); } @Transactional(rollbackFor = Exception.class) public void update**(XX xx) { //3.数据库更新写入 }

这里需要注意，注解事务的用法，方法必须是公开调用的。

三：HttpClient 4.x连接池

当时找到数据连接池泄露的原因后，我第一步就是去掉了事务，然后加上了一些日志，这时我已经能确定代码在jenkinsclient处出现了问题，但是仍然不确定问题出在了哪，我只能加上一些日志，同时通过监控继续观察。

果然在hotfix的第二天还是出现了我预料中的事情，构建发布仍然有问题，当然此时其它功能是不受影响了。我观察日志发现构建开始并在该处阻塞