前段时间有应用使用Druid连接池经常的提示断链报错，整个问题排查分析过程很有意思。这里将Druid连接池、数据库层以及负载均衡层的配置分析下，记录整个问题的分析过程，同时梳理下Druid连接池的配置和连接保活及回收机制。
应用通过数据库连接池申请连接，再通过负载均衡连接到数据库代理然后访问数据库，这是一个典型的架构，如下图所示：
但是系统上线后应用总是出现偶发性的断链报错，经常性的出现以下错误信息：
discard connection
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet successfully received from the server was 72,557 milliseconds ago. The last packet sent successfully to the server was 0 milliseconds ago.
根据错误日志初步判断肯定是与 DB之间的链接已经断开，尝试使用了一个已经断开的链接才会引起这个错误发生，但是根据Druid的连接检查功能，不应出现这样的问题。接下去了解下Druid连接池的基本配置以及连接保活和回收机制。
Druid是开源的数据库连接池，它结合了C3P0、DBCP、Proxool等DB池的优点，同时加入了日志监控，可以很好的监控DB池连接和SQL的执行情况。
1）基本属性
2）连接池大小
3）连接检测
4）缓存语句
使用druid连接池，主要是使用DruidDataSourceFactory创建出DataSource数据源对象，然后调用其getConnection方法获取数据库连接对象，拿到连接对象之后，和其它数据库连接不同的是当调用连接的close方法时，底层不再是关闭销毁连接对象，而是将连接对象放入到连接池中，以便后续新的请求到来时，直接拿去使用。
import com.alibaba.druid.pool.DruidDataSourceFactory;
import javax.sql.DataSource;
import java.io.InputStream;
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.util.Properties;
public class druidtest {
public static void main(String[] args) throws Exception {
//加载配置文件
InputStream is = druidtest.class.getClassLoader().getResourceAsStream("druid.properties");
Properties prop = new Properties();
prop.load(is);
//根据配置文件内容，创建出数据源对象
DataSource dataSource = DruidDataSourceFactory.createDataSource(prop);
//通过数据源对象获取数据库连接
//如果连接池中的连接已经被用完，则会等待一定的时间（所配置的时间）
//如果等待超时，就会抛出异常
Connection con = dataSource.getConnection();
//执行 sql 语句，获取并打印结果集
String sql = "select e_id,e_name,e_age from employee";
PreparedStatement pst = con.prepareStatement(sql);
ResultSet rs = pst.executeQuery();
while(rs.next()) {
System.out.println(
rs.getInt("e_id") + "\t" +
rs.getString("e_name") + "\t" +
rs.getInt("e_age"));
}
//释放资源
rs.close();
pst.close();
//这里的关闭连接，并没有关闭和销毁连接而是把连接对象，放入到连接池中，供后续访问时直接拿去使用
con.close();
}
}
注意其中的con.close()，这里的关闭连接，并没有关闭和销毁连接而是把连接对象，放入到连接池中，供后续访问时直接拿去使用。
为了防止一个数据库连接太久没有使用，而被其它下层的服务关闭，druid中定义了KeepAlive选项，机制上与TCP中的类似。保活机制能够保证连接池中的连接是真实有效的连接，假如遇到特殊情况导致连接不可用时，keepAlive机制将无效连接进行驱逐。保活机制是由守护线程DestroyConnectionThread发起的，启动后守护线程会进入无线循环，根据心跳间隔时间timeBetweenEvictionRunsMillis循环调用DestoryTask线程，默认时间为60s。
1）开启KeepAlive
// 一个连接在连接池中最小生存的时间
dataSurce.setMinEvictableIdleTimeMillis(60 * 1000);单位毫秒
// 开启keepAlive
dataSource.setKeepAlive(true);
2）DruidDataSource中的两个成员变量
// 存放检查需要抛弃的连接
private DruidConnectionHolder[] evictConnections;
// 用来存放需要连接检查的存活连接
private DruidConnectionHolder[] keepAliveConnections;
如果KeepAlive打开，当一个连接的空闲时间超过keepAliveBetweenTimeMillis时，则会将此连接放入此连接放入keepAliveConnections数组，然后使用validationQuery执行一次查询。
if (keepAlive && idleMillis >= keepAliveBetweenTimeMillis) {
keepAliveConnections[keepAliveCount++] = connection;
}
…
if (keepAliveCount > 0) {
// keep order
for (int i = keepAliveCount - 1; i >= 0; --i) {
DruidConnectionHolder holer = keepAliveConnections[i];
Connection connection = holer.getConnection();
holer.incrementKeepAliveCheckCount();
boolean validate = false;
try {
this.validateConnection(connection);
validate = true;
} catch (Throwable error) {
if (LOG.isDebugEnabled()) {
LOG.debug("keepAliveErr", error);
}
// skip
}
如果本次validationQuery执行失败，则关闭该链接，并丢弃。
在Druid数据源初始化的时候，会创建一个定时运行的DestroyTask，该任务的主要目的是将已空闲时间满足关闭条件的连接关闭。
1）当前连接存活时长 > 配置的物理连接时间时长，则放入evictConnections
if (phyConnectTimeMillis > phyTimeoutMillis) {
evictConnections[evictCount++] = connection;
continue;
}
2）空闲时间 > 最小驱逐时间
if (idleMillis >= minEvictableIdleTimeMillis) {
if (checkTime && i < checkCount) {
evictConnections[evictCount++] = connection;
continue;
} else if (idleMillis > maxEvictableIdleTimeMillis) {
evictConnections[evictCount++] = connection;
continue;
}
}
…
if (evictCount > 0) {
for (int i = 0; i < evictCount; ++i) {
DruidConnectionHolder item = evictConnections[i];
Connection connection = item.getConnection();
JdbcUtils.close(connection);
destroyCountUpdater.incrementAndGet(this);
}
Arrays.fill(evictConnections, null);
}
从代码逻辑中可以看到，对于要关闭的空闲连接选择逻辑如下：
Druid连接的生命周期从两个维度去看：一个是应用使用方，包括连接的申请、使用和关闭；一个是Druid自己管理的连接池，包括连接的创建和回收、保活机制等。具体如下所示：
1）客户端连接管理
2）Druid连接池管理
回到应用断链的问题，基于Druid连接池的设置和应用访问数据库整个链路的超时设置，以MySQL数据库为例，可以得到下面配置：
JDBC的url连接配置中connectTimeout和socketTimeout都属于TCP层面的超时
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
...
Caused by: java.net.SocketTimeoutException: connect timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
...
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet successfully received from the server was 3,080 milliseconds ago. The last packet sent successfully to the server was 3,005 milliseconds ago.
...
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
以MySQL为例，在数据库层设置空闲连接的超时参数wait_timeout，默认为7小时，超过后会自动断开空闲连接。在实际过程中，应用通过负载均衡或者Druid连接到数据库，如果负载均衡没有开启会话保持或者Druid没有连接保活机制，客户端的连接空闲时间超过7小时后，会在数据库层主动杀掉。但是既然已经使用了Druid连接池，那么应用端的数据库连接就可以由Druid进行很好的管理。
从应用断链报错信息来看，不是超过7小时断开，而是300s左右，所以排除了数据库层主动断链的问题。再来分析下Druid端的配置，和连接有关的参数如下：
datasource.druid.validationQuery=SELECT 1 from dual
datasource.druid.validationQueryTimeout=2000
datasource.druid.testWhileIdle=true
datasource.druid.minIdle=50
datasource.druid.maxActive=100
datasource.druid.minEvictableIdleTimeMillis=300000
datasource.druid.timeBetweenEvictionRunsMillis=600000
datasource.druid.keepAlive=true
datasource.druid.keepAliveBetweenTimeMillis=300s
有一点很容易忽略的就是负载均衡的会话保持，会话保持是指在负载均衡器上有一种机制，在作负载均衡的同时，还保证同一用户相关连的访问请求会被分配到同一台服务器上。会话保持是有时间限制的，以F5为例默认为5分钟，也就是检测到连接空闲超过5分钟，会主动将它断开。这里似乎找到了问题点了，Druid连接池的保活是10分钟而负载均衡这边的空闲连接检测是5分钟，当有连接的空闲时间超过5分钟但是小于10分钟后，会被负载均衡这边杀掉，应用在使用这个连接的时候当然会报断链的错误了。最后是调整了负载均衡的会话保持的检测时间，以规避类似的问题。
应用在使用Druid连接池访问数据库的时候，需要根据业务TPS和并发调整合适的配置，以利用Druid连接池的实现对连接的创建、保活和释放管理。当遇到类似断链的问题的时候，要从端到端的每个点进行排查分析，以定位到最终的原因，比如这次的负载均衡的配置是很难想到的。应用从Druid申请了连接后，这个连接已经超出Druid的管理范围，需要由应用自己去做处理，及时的close归还到连接池里，否则的话数据库端的连接会越来越多，而且空闲连接超过一定时间后也会被数据库层或者负载均衡层断掉进而出现断链的错误，这个就需要应用做额外的处理了。
参考资料：
转载请注明原文地址：https://blog.csdn.net/solihawk/article/details/125612396
文章会同步在公众号“牧羊人的方向”更新，感兴趣的可以关注公众号，谢谢！
