数据库连接池的原因导致线上问题的总结

背景

上周线上出了一个问题，现象如下：

1. 前端的出现了部分请求访问超时
2. 后台服务（3个节点）没有任何报错信息

处理

通过查看 3 个节点上后台服务的日志，发现由于定时调度策略的问题致使所有的任务都被调度到了同 1 个节点上，而另外 2 个节点则无定时任务运行。针对这个现象，猜测是这个运行定时任务的节点出现了问题，致使被分发到该节点上的请求无法正常返回。为了快速解决线上的问题，抱着试一试的心态重启了该节点上的服务。感谢上帝爸爸，一切回归正常了（长舒了一口气~~）。

分析

表面上问题貌似被解决了，但是真的是解决了吗（心里一直不踏实）？到底为啥运行定时任务的那个节点出问题了呢？而这个问题到底又是啥呢？

带着这个问题，我又查看了这个服务中与定时任务相关的代码，发现在这个服务里同一时刻（都是设置成一分钟执行一次）会同时启动多个定时任务，其中有几个定时任务是查出一批数据后再对数据逐个进行数据库操作（很频繁的数据库操作哦！）。

会不会是由于频繁的数据库操作使连接池中的连接数量不够，导致其他业务的请求获取连接的时候需要排队，这样就很有可能会造成前端超时（获取数据库连接+处理业务的时间超过了超时时间）的现象。说的再直接点儿，就是定时任务和前端请求争抢有限的数据库连接资源。为了验证这个判断，我又检查了一下数据库连接池的配置信息：

（注：以下配置信息是对 druid 进行了包装）

# 初始化大小，最小，最大
annoroad_mybatis.datasource_initial_size=5
annoroad_mybatis.datasource_min_idle=5
annoroad_mybatis.datasource_max_active=20
# 配置获取连接等待超时的时间
annoroad_mybatis.datasource_max_wait=60000

通过上边的配置信息，我们可以看出来连接池最大可以有 20 个连接。这样看来，定时任务有很大机会把这 20 个连接都抢光，从而使之后的请求（可能是定时任务产生的，也可能是前端请求产生的）只能等待连接被释放…

总结

从现象来看，该问题的原因应该就出在数据库连接池配置上，定时任务影响了从前端过来的请求，最后通过一张图来做个总结：