解决Mysql连接8小时空闲失效问题

博主在之前的博文中发过一篇博客，是关于flink高性能写入mysql或者Oracle的问题，虽然写入的性能提高了，但是在接下来其他项目的开发过程中，遇到过连接connection失效的问题。

博主的使用场景是这样的：

博主的项目是做的实时推送的工程，每推送成功一条，就插入mysql一条数据，考虑到夜晚对用户推送，可能会对用户有打扰，所以在22~07不对用户进行推送，因此在这个空档期，mysql的连接是没有使用的，所以会报connection连接失效，至此，博主之前提到的高性能写入mysql的方案就行不通了，因为那样的方式是不能设置connection的失效时间及检测的，在c3p0不理想的情况下，此次博主采用了DBCP连接池。
使用到的maven

        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-dbcp2</artifactId>
            <version>2.5.0</version>
        </dependency>

本人使用的工具类如下

package com.chinaTelecom.mySqlUtiles;

import org.apache.commons.dbcp2.BasicDataSource;

import javax.sql.DataSource;
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;

public class DBCPUtils {
    //建立连接的驱动驱动名称
    public static final String DRIVER_CLASS_NAME = "***";
    //数据库链接数据哭的url
    public static final String URL = "***";
    //链接的数据库账号
    public static final String USERNAME = "***";
    //链接的数据库密码
    public static final String PASSWORD = "***";
    //初始化时链接池的数量
    private static final int INITIAL_SIZE = 10;
    //的到链接实例
    private static BasicDataSource dataSource = new BasicDataSource();
    //初始化链接参数
    static{
        dataSource.setDriverClassName(DRIVER_CLASS_NAME);
        dataSource.setUrl(URL);
        dataSource.setUsername(USERNAME);
        dataSource.setPassword(PASSWORD);

        dataSource.setInitialSize(INITIAL_SIZE);   //初始化连接:连接池启动时创建的初始化连接数量
        dataSource.setMaxTotal(10);
        dataSource.setMaxIdle(6);   //最大空闲连接:连接池中容许保持空闲状态的最大连接数量,超过的空闲连接将被释放,如果设置为负数表示不限制
        dataSource.setMinIdle(4);   //最小空闲连接:连接池中容许保持空闲状态的最小连接数量,低于这个数量将创建新的连接,如果设置为0则不创建
        dataSource.setMinEvictableIdleTimeMillis(1000 * 60 * 60 * 10);  //连接在池中保持空闲而不被空闲连接回收器线程(如果有)回收的最小时间值，单位毫秒
        dataSource.setTestOnBorrow(true);  //是否在从池中取出连接前进行检验,如果检验失败,则从池中去除连接并尝试取出另一个.
        dataSource.setTestOnCreate(true);  //指明对象在创建后是否需要验证是否有效，如果对象验证失败，则触发对象创建的租借尝试将失败。
        dataSource.setTestWhileIdle(true);  //指明对象是否需要通过对象驱逐者进行校验（如果有的话），假如一个对象验证失败，则对象将被从池中释放。和timeBetweenEvictionRunsMillis配合使用。
        dataSource.setTimeBetweenEvictionRunsMillis(100000); //在空闲连接回收器线程运行期间休眠的时间值，以毫秒为单位，即每100秒做一次idle连接的检测，检测语句为validationQuery。
        dataSource.setValidationQuery("select 1"); //SQL查询，用来验证从连接池取出的连接，验证连接是否有效，查询必须是一个SQL SELECT并且必须返回至少一行记录。
        dataSource.setNumTestsPerEvictionRun(10);  //每次空闲连接回收器线程运行时检查的连接数量
    }
    //提供获得数据源
    public static DataSource getDateSource(){
        return dataSource;
    }
    //提供获得链接
    public static Connection getConnection() throws SQLException {
        return dataSource.getConnection();
    }

	//测试connection是否正常
    public static void main(String[] args) throws SQLException {
        Connection connection = DBCPUtils.getConnection();
        PreparedStatement ps = connection.prepareStatement("select * from phoneNum");
        ResultSet rs = ps.executeQuery();
        while (rs.next()){
            String string = rs.getString(2);
            System.out.println(string);
        }
    }
}

参数解读：
testOnBorrow=false 表示使用连接池中的连接时，不做检测，这个也是推荐配置，如果设置为true会影响数据库的性能。

testWhileIdle=true 指明连接是否被空闲连接回收器进行检验，如果检测失败，则连接将被从池中去除，和timeBetweenEvictionRunsMillis配合使用。

validationQuery=select 1 SQL查询，用来验证从连接池取出的连接，验证连接是否有效，查询必须是一个SQL SELECT并且必须返回至少一行记录。

timeBetweenEvictionRunsMillis=100000 在空闲连接回收器线程运行期间休眠的时间值，以毫秒为单位，即每100秒做一次idle连接的检测，检测语句为validationQuery。

minEvictableIdleTimeMillis=600000 连接在池中保持空闲而不被空闲连接回收器线程，即idle连接的保存时间为600秒(10分钟)

感觉没有问题，每100秒就会做idle线程的检测，应用的检测时间600秒也小于数据库设置的1800秒的时间，为什么还会有连接失效的异常？且报的连接失效时长越来越长。

分析：
看dbcp源码看到还有一个参数numTestsPerEvictionRun ，在每次空闲连接回收器线程运行时检查的连接数量，这个参数配置了每100秒检测的idle线程的数量。这个参数我们没有配置，走的是默认值。

protected int numTestsPerEvictionRun = 3;

源码中配置的是3，就是默认每次只检测3个idle线程。

按照最坏的情况，最大的idle线程为800，每100秒执行3个idle线程的判断，判断完所有的idle线程的状态需要 (800/3) * 100秒=26666秒，而数据库的超时是1800秒，这意味着如果池子满了(或者池子中的连接数很多)的话，到所有的idle线程都检测完成，应用是很大概率会取到已经失效的连接的。最早的超时连接应该是在30分钟之后也就是数据库配置的1800秒

解决：
网上大家的推荐配置是设置numTestsPerEvictionRun=maxIdle，这样一次检测就都可以把失效的idle都移出线程池，避免了一个高峰之后，连接池的连接已经失效的问题。

鉴于失效的连接会被慢慢的剔除，当时没有做修改配置的操作，之后会把numTestsPerEvictionRun参数配置成和maxIdle一样的值，可以避免这个问题的发生。

解决Mysql连接8小时空闲失效问题

猜你喜欢