程序博客网 > 淘宝流量如何提升

dbcp基本配置和重连配置

来源：互联网 发布：淘宝流量如何提升 编辑：程序博客网 时间：2024/05/16 06:41


1. 引入dbcp (选择1.4)

Java代码  收藏代码
  1. <dependency>  
  2.     <groupId>com.alibaba.external</groupId>  
  3.     <artifactId>jakarta.commons.dbcp</artifactId>  
  4.     <version>1.4</version>  
  5. </dependency>  

 

2. dbcp的基本配置

相关配置说明:

 

  1. initialSize ：连接池启动时创建的初始化连接数量（默认值为0）
  2. maxActive ：连接池中可同时连接的最大的连接数（默认值为8，调整为20，高峰单机器在20并发左右，自己根据应用场景定）
  3. maxIdle：连接池中最大的空闲的连接数，超过的空闲连接将被释放，如果设置为负数表示不限制（默认为8个，maxIdle不能设置太小，因为假如在高负载的情况下，连接的打开时间比关闭的时间快，会引起连接池中idle的个数 上升超过maxIdle，而造成频繁的连接销毁和创建，类似于jvm参数中的Xmx设置)
  4. minIdle：连接池中最小的空闲的连接数，低于这个数量会被创建新的连接（默认为0，调整为5，该参数越接近maxIdle，性能越好，因为连接的创建和销毁，都是需要消耗资源的；但是不能太大，因为在机器很空闲的时候，也会创建低于minidle个数的连接，类似于jvm参数中的Xmn设置）
  5. maxWait ：最大等待时间，当没有可用连接时，连接池等待连接释放的最大时间，超过该时间限制会抛出异常，如果设置-1表示无限等待（默认为无限，调整为60000ms，避免因线程池不够用，而导致请求被无限制挂起）
  6. poolPreparedStatements：开启池的prepared（默认是false，未调整，经过测试，开启后的性能没有关闭的好。）
  7. maxOpenPreparedStatements：开启池的prepared 后的同时最大连接数（默认无限制，同上，未配置）
  8. minEvictableIdleTimeMillis ：连接池中连接，在时间段内一直空闲， 被逐出连接池的时间
  9. （默认为30分钟，可以适当做调整，需要和后端服务端的策略配置相关）
  10. removeAbandonedTimeout ：超过时间限制，回收没有用(废弃)的连接（默认为 300秒，调整为180）
  11. removeAbandoned ：超过removeAbandonedTimeout时间后，是否进 行没用连接（废弃）的回收（默认为false，调整为true)

removeAbandoned参数解释：
  1. 如果开启了removeAbandoned，当getNumIdle() < 2) and (getNumActive() > getMaxActive() - 3)时被触发.
  2. 举例当maxActive=20, 活动连接为18,空闲连接为1时可以触发"removeAbandoned".但是活动连接只有在没有被使用的时间超 过"removeAbandonedTimeout"时才被回收
  3. logAbandoned： 标记当连接被回收时是否打印程序的stack traces日志（默认为false，未调整）

一般会是几种情况出现需要removeAbandoned：　
  1. 代码未在finally释放connection ,　不过我们都用sqlmapClientTemplate，底层都有链接释放的过程
  2. 遇到数据库死锁。以前遇到过后端存储过程做了锁表操作，导致前台集群中连接池全都被block住，后续的业务处理因为拿不到链接所有都处理失败了。

一份优化过的配置：
基本配置代码  收藏代码
  1. <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">   
  2.     <property name="driverClassName" value="com.mysql.jdbc.Driver" />  
  3.     <property name="url" value="xxxx" />  
  4.     <property name="username"><value>xxxx</value></property>  
  5.         <property name="password"><value>xxxxx</value></property>  
  6.         <property name="maxActive"><value>20</value></property>  
  7.         <property name="initialSize"><value>1</value></property>  
  8.         <property name="maxWait"><value>60000</value></property>  
  9.         <property name="maxIdle"><value>20</value></property>  
  10.         <property name="minIdle"><value>3</value></property>  
  11.         <property name="removeAbandoned"><value>true</value></property>  
  12.         <property name="removeAbandonedTimeout"><value>180</value></property>  
  13.         <property name="connectionProperties"><value>clientEncoding=GBK</value></property>  
  14. </bean>  
 
 

2. dbcp的链接validate配置
  1. dbcp是采用了commons-pool做为其连接池管理，testOnBorrow,testOnReturn, testWhileIdle是pool是提供的几种校验机制，通过外部钩子的方式回调dbcp的相关数据库链接(validationQuery)校验
  2. dbcp相关外部钩子类：PoolableConnectionFactory,继承于common-pool PoolableObjectFactory
  3. dbcp通过GenericObjectPool这一入口，进行连接池的borrow,return处理
  4. testOnBorrow : 顾明思义，就是在进行borrowObject进行处理时，对拿到的connection进行validateObject校验
  5. testOnReturn : 顾明思义，就是在进行returnObject对返回的connection进行validateObject校验，个人觉得对数据库连接池的管理意义不大
  6. testWhileIdle : 关注的重点，GenericObjectPool中针对pool管理，起了一个Evict的TimerTask定时线程进行控制(可通过设置参数timeBetweenEvictionRunsMillis>0),定时对线程池中的链接进行validateObject校验，对无效的链接进行关闭后，会调用ensureMinIdle，适当建立链接保证最小的minIdle连接数。
  7. timeBetweenEvictionRunsMillis,设置的Evict线程的时间，单位ms，大于0才会开启evict检查线程
  8. validateQuery， 代表检查的sql
  9. validateQueryTimeout， 代表在执行检查时，通过statement设置，statement.setQueryTimeout(validationQueryTimeout)
  10. numTestsPerEvictionRun，代表每次检查链接的数量，建议设置和maxActive一样大，这样每次可以有效检查所有的链接.

Validate配置代码  收藏代码
  1. <property name="testWhileIdle"><value>true</value></property> <!-- 打开检查,用异步线程evict进行检查 -->  
  2.     <property name="testOnBorrow"><value>false</value></property>  
  3.     <property name="testOnReturn"><value>false</value></property>  
  4.     <property name="validationQuery"><value>select sysdate from dual</value></property>  
  5.     <property name="validationQueryTimeout"><value>1</value></property>  
  6.     <property name="timeBetweenEvictionRunsMillis"><value>30000</value></property>  
  7.     <property name="numTestsPerEvictionRun"><value>20</value></property>  

 相关配置需求：

 

  1. 目前网站的应用大部分的瓶颈还是在I/O这一块，大部分的I/O还是在数据库的这一层面上，每一个请求可能会调用10来次SQL查询，如果不走事务，一个请求会重复获取链接，如果每次获取链接都进行validateObject，性能开销不是很能接受，可以假定一次SQL操作消毫0.5~1ms(一般走了网络请求基本就这数)
  2. 网站异常数据库重启，网络异常断开的频率是非常低的，一般也就在数据库升级，演习维护时才会进行，而且一般也是选在晚上，访问量相对比较低的请求，而且一般会有人员值班关注，所以异步的validateObject是可以接受，但一个前提需要确保能保证在一个合理的时间段内，数据库能完成自动重联。

从代码层面简单介绍下dbcp的validate实现：

1.  common-pools提供的PoolableObjectFactory，针对pool池的管理操作接口

 

Java代码  收藏代码
  1. public interface PoolableObjectFactory {  
  2.   
  3.   Object makeObject() throws Exception;  
  4.   
  5.   void destroyObject(Object obj) throws Exception;  
  6.   
  7.   boolean validateObject(Object obj);  
  8.   
  9.   void activateObject(Object obj) throws Exception;  
  10.   
  11.   void passivateObject(Object obj) throws Exception;  
  12. }  

 

 

2. dbcp实现的pool从池管理操作

 

这里贴了一个相关validate代码，具体类可见：PoolableConnectionFactory.validateConnection()

 

Java代码  收藏代码
  1. public class PoolableConnectionFactory implements PoolableObjectFactory {  
  2.   
  3. ......  
  4. public boolean validateObject(Object obj) { //验证validateObject  
  5.         if(obj instanceof Connection) {  
  6.             try {  
  7.                 validateConnection((Connection) obj);  
  8.                 return true;  
  9.             } catch(Exception e) {  
  10.                 return false;  
  11.             }  
  12.         } else {  
  13.             return false;  
  14.         }  
  15.     }  
  16. public void validateConnection(Connection conn) throws SQLException {  
  17.         String query = _validationQuery;  
  18.         if(conn.isClosed()) {  
  19.             throw new SQLException("validateConnection: connection closed");  
  20.         }  
  21.         if(null != query) {  
  22.             Statement stmt = null;  
  23.             ResultSet rset = null;  
  24.             try {  
  25.                 stmt = conn.createStatement();  
  26.                 if (_validationQueryTimeout > 0) {  
  27.                     stmt.setQueryTimeout(_validationQueryTimeout);  
  28.                 }  
  29.                 rset = stmt.executeQuery(query);  
  30.                 if(!rset.next()) {  
  31.                     throw new SQLException("validationQuery didn't return a row");  
  32.                 }  
  33.             } finally {  
  34.                 if (rset != null) {  
  35.                     try {  
  36.                         rset.close();  
  37.                     } catch(Exception t) {  
  38.                         // ignored  
  39.                     }  
  40.                 }  
  41.                 if (stmt != null) {  
  42.                     try {  
  43.                         stmt.close();  
  44.                     } catch(Exception t) {  
  45.                         // ignored  
  46.                     }  
  47.                 }  
  48.             }  
  49.         }  
  50.     }  
  51.   
  52. ....  
  53.   
  54. }  

 

3. pool池的evict调用代码：GenericObjectPool (apache commons pool version 1.5.4)

Java代码  收藏代码
  1. protected synchronized void startEvictor(long delay) { //启动Evictor为TimerTask  
  2.         if(null != _evictor) {  
  3.             EvictionTimer.cancel(_evictor);  
  4.             _evictor = null;  
  5.         }  
  6.         if(delay > 0) {  
  7.             _evictor = new Evictor();  
  8.             EvictionTimer.schedule(_evictor, delay, delay);  
  9.         }  
  10.     }  
  11.   
  12. for (int i=0,m=getNumTests();i<m;i++) {  
  13.             final ObjectTimestampPair pair;  
  14.            .......  
  15.             boolean removeObject = false;  
  16.             // 空闲链接处理  
  17.             final long idleTimeMilis = System.currentTimeMillis() - pair.tstamp;  
  18.             if ((getMinEvictableIdleTimeMillis() > 0) &&  
  19.                     (idleTimeMilis > getMinEvictableIdleTimeMillis())) {  
  20.                 removeObject = true;  
  21.             } else if ((getSoftMinEvictableIdleTimeMillis() > 0) &&  
  22.                     (idleTimeMilis > getSoftMinEvictableIdleTimeMillis()) &&  
  23.                     ((getNumIdle() + 1)> getMinIdle())) {   
  24.                 removeObject = true;  
  25.             }  
  26.             //  testWhileIdle sql 检查处理  
  27.             if(getTestWhileIdle() && !removeObject) {  
  28.                 boolean active = false;  
  29.                 try {  
  30.                     _factory.activateObject(pair.value);  
  31.                     active = true;  
  32.                 } catch(Exception e) {  
  33.                     removeObject=true;  
  34.                 }  
  35.                 if(active) {  
  36.                     if(!_factory.validateObject(pair.value)) {   
  37.                         removeObject=true;  
  38.                     } else {  
  39.                         try {  
  40.                             _factory.passivateObject(pair.value);  
  41.                         } catch(Exception e) {  
  42.                             removeObject=true;  
  43.                         }  
  44.                     }  
  45.                 }  
  46.             }  
  47.             // 真正关闭  
  48.             if (removeObject) {  
  49.                 try {  
  50.                     _factory.destroyObject(pair.value);  
  51.                 } catch(Exception e) {  
  52.                     // ignored  
  53.                 }  
  54.             }  
  55.           ........  
 

注意： 目前dbcp的pool的实现是使用了公用的apache common pools进行扩展处理，所以和原生的连接池处理，代码看上去有点别扭，感觉自动重连这块异常处理不怎么好，我也就只重点关注了这部分代码而已  .


 

3. dbcp的链接自动重链相关测试

相关场景：

  1. 数据库意外重启后，原先的数据库连接池能自动废弃老的无用的链接，建立新的数据库链接
  2. 网络异常中断后，原先的建立的tcp链接，应该能进行自动切换

测试需求1步骤

  1. 建立一testCase代码
  2. 配置mysql数据库
  3. 循环执行在SQL查询过程
  4. 异常重启mysql数据库

测试需求2步骤

  1. 建立一testCase代码
  2. 配置mysql数据库
  3. 循环执行在SQL查询过程
  4. 通过iptables禁用网络链接

/sbin/iptables -A INPUT -s 10.16.2.69 -j REJECT
/sbin/iptables -A FORWARD -p tcp -s 10.16.2.69 --dport 3306 -m state --state NEW,ESTABLISHED -j DROP

     5. iptables -F 清空规则，恢复链接通道。

 

测试需求问题记录

 

分别测试了两种配置，有validateObject的配置和没有validateObject的相关配置。

1. 没有validate配置
问题一： 异常重启mysql数据库后，居然也可以自动恢复链接，sql查询正常
跟踪了一下代码，发现这么一个问题：

  1. 在数据库关闭的时候，client中pool通过borrowObject获取一个异常链接返回给client
  2. client在使用具体的异常链接进行sql调用出错了，抛了异常
  3. 在finally，调用connection.close()，本意是应该调用pool通过returnObject返回到的池中，但在跟踪代码时，未见调用GenericObjectPool的returnObject
  4. 继续查，发现在dbcp在中PoolingDataSource(实现DataSource接口)调用PoolableConnection(dbcp pool相关的delegate操作)进行相应关闭时，会检查_conn.isClosed()，针对DataSource如果isClosed返回为true的则不调用returnObject，直接丢弃了链接  

解释：

  • 正因为在获取异常链接后，因为做了_conn.isClosed()判断，所以异常链接并没有返回到连接池中，所以到数据库重启恢复后，每次都是调用pool重新构造一个新的connection，所以后面就正常了
  • _conn.isClosed()是否保险，从jdk的api描述中： A connection is closed if the method close has been called on it or if certain fatal errors have occurred. 里面提供两种情况，一种就是被调用了closed方法，另一种就是出现一些异常也说的比较含糊。

问题二：validateObject调用时，dbcp设置的validationQueryTimeout居然没效果

看了mysql statement代码实现，找到了答案。 

mysql com.mysql.jdbc.statemen 部分代码

 

timeout时间处理：

Java代码  收藏代码
  1. timeoutTask = new CancelTask();  
  2. //通过TimerTask启动一定时任务  
  3. Connection.getCancelTimer().schedule(timeoutTask,  this.timeoutInMillis);  

 

对应的CancelTask的代码： 

 

Java代码  收藏代码
  1. class CancelTask extends TimerTask {  
  2.   
  3.         long connectionId = 0;  
  4.   
  5.         CancelTask() throws SQLException {  
  6.             connectionId = connection.getIO().getThreadId();  
  7.         }  
  8.   
  9.         public void run() {  
  10.   
  11.             Thread cancelThread = new Thread() {  
  12.   
  13.                 public void run() {  
  14.                     Connection cancelConn = null;  
  15.                     java.sql.Statement cancelStmt = null;  
  16.   
  17.                     try {  
  18.                         cancelConn = connection.duplicate();  
  19.                         cancelStmt = cancelConn.createStatement();  
  20.                                                 // 简单暴力，再发起一条KILL SQL，关闭先前的sql thread id  
  21.                         cancelStmt.execute("KILL QUERY " + connectionId);  
  22.                         wasCancelled = true;  
  23.                     } catch (SQLException sqlEx) {  
  24.                         throw new RuntimeException(sqlEx.toString());  
  25.                     } finally {  
  26.                         if (cancelStmt != null) {  
  27.                             try {  
  28.                                 cancelStmt.close();  
  29.                             } catch (SQLException sqlEx) {  
  30.                                 throw new RuntimeException(sqlEx.toString());  
  31.                             }  
  32.                         }  
  33.   
  34.                         if (cancelConn != null) {  
  35.                             try {  
  36.                                 cancelConn.close();  
  37.                             } catch (SQLException sqlEx) {  
  38.                                 throw new RuntimeException(sqlEx.toString());  
  39.                             }  
  40.                         }  
  41.                     }  
  42.                 }  
  43.             };  
  44.   
  45.             cancelThread.start();  
  46.         }  
  47.     }  

 

 

原因总结一句话： queryTimeout的实现是通过底层数据库提供的机制，比如KILL QUERY pid.  如果此时的网络不通，出现阻塞现象，对应的kill命令也发不出去，所以timeout设置的超时没效果。

4.最后

最后还是决定配置testWhileIdle扫描，主要考虑：

  1. pool池中的链接如果未被使用，可以通过testWhileIdle进行链接检查，避免在使用时后总要失败那么一次，可以及时预防
  2. 配合连接池的minEvictableIdleTimeMillis(空闲链接)，removeAbandoned(未释放的链接)，可以更好的去避免因为一些异常情况引起的问题，防范于未然。比如使用一些分布式数据库的中间件，会有空闲链接关闭的动作，动态伸缩连接池，这时候需要能及时的发现，避免请求失败。
  3. testOnBorrow个人不太建议使用，存在性能问题，试想一下连接一般会在什么情况出问题，网络或者服务端异常终端空闲链接，网络中断你testOnBorrow检查发现不对再取一个链接还是不对，针对空闲链接处理异常关闭，可以从好业务端的重试策略进行考虑，同时配置客户端的空闲链接超时时间，maxIdle,minIdle等。

 

--------------------------------------------

新加的内容：

5.dbcp密码加密处理

以前使用jboss的jndi数据源的方式，是通过配置oracle-ds.xml，可以设置<security-domain>EncryptDBPassword</security-domain>，引用jboss login-config.xml配置的加密配置。

 

 

Java代码  收藏代码
  1. <application-policy name="EncryptDBPassword">  
  2.         <authentication>  
  3.             <login-module code="org.jboss.resource.security.SecureIdentityLoginModule" flag="required">  
  4.                 <module-option name="username">${username}</module-option>  
  5.                 <module-option name="password">${password_encrypt}</module-option>  
  6.                 <module-option name="managedConnectionFactoryName">jboss.jca:service=LocalTxCM,name=${jndiName}</module-option>  
  7.             </login-module>  
  8.         </authentication>  
  9.     </application-policy>  
 

 

为了能达到同样的效果，切换为spring dbcp配置时，也有类似密码加密的功能，运行期进行密码decode,最后进行数据链接。

 

 

实现方式很简单，分析jboss的对应SecureIdentityLoginModule的实现，无非就是走了Blowfish加密算法，自己拷贝实现一份。

 

 

Java代码  收藏代码
  1. private static String encode(String secret) throws NoSuchPaddingException, NoSuchAlgorithmException,  
  2.                                                InvalidKeyException, BadPaddingException, IllegalBlockSizeException {  
  3.         byte[] kbytes = "jaas is the way".getBytes();  
  4.         SecretKeySpec key = new SecretKeySpec(kbytes, "Blowfish");  
  5.   
  6.         Cipher cipher = Cipher.getInstance("Blowfish");  
  7.         cipher.init(Cipher.ENCRYPT_MODE, key);  
  8.         byte[] encoding = cipher.doFinal(secret.getBytes());  
  9.         BigInteger n = new BigInteger(encoding);  
  10.         return n.toString(16);  
  11.     }  
  12.   
  13.     private static char[] decode(String secret) throws NoSuchPaddingException, NoSuchAlgorithmException,  
  14.                                                InvalidKeyException, BadPaddingException, IllegalBlockSizeException {  
  15.         byte[] kbytes = "jaas is the way".getBytes();  
  16.         SecretKeySpec key = new SecretKeySpec(kbytes, "Blowfish");  
  17.   
  18.         BigInteger n = new BigInteger(secret, 16);  
  19.         byte[] encoding = n.toByteArray();  
  20.   
  21.         Cipher cipher = Cipher.getInstance("Blowfish");  
  22.         cipher.init(Cipher.DECRYPT_MODE, key);  
  23.         byte[] decode = cipher.doFinal(encoding);  
  24.         return new String(decode).toCharArray();  
  25.     }  
 

最后的配置替换为：

 

 

Xml代码  收藏代码
  1. <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">   
  2. ......  
  3.         <property name="password"><!-- 注意多了一层转化，将密码串调用decode解密为最初的数据库密码 -->  
  4.             <bean class="com.xxxxx.EncryptDBPasswordFactory">  
  5.                 <property name="password" value="${xxxx.password.encrypted}" />  
  6.             </bean>  
  7.         </property>  
  8. ........  
  9. </bean>  

 

--------------------------------------------

新加的内容：

6.数据库重连机制

常见的问题：

1. 数据库意外重启后，原先的数据库连接池能自动废弃老的无用的链接，建立新的数据库链接

2. 网络异常中断后，原先的建立的tcp链接，应该能进行自动切换。比如网站演习中的交换机重启会导致网络瞬断

3. 分布式数据库中间件，比如amoeba会定时的将空闲链接异常关闭，客户端会出现半开的空闲链接。

 

大致的解决思路： 

1. sql心跳检查

  主动式 ,即我前面提到的sql validate相关配置

2. 请求探雷

    牺牲小我，完成大我的精神。 拿链接尝试一下，发现处理失败丢弃链接，探雷的请求总会失败几个，就是前面遇到的问题一，dbcp已经支持该功能，不需要额外置。

3. 设置合理的超时时间，

      解决半开链接. 一般数据库mysql,oracle都有一定的链接空闲断开的机制，而且当你使用一些分布式中间件(软件一类的)，空闲链接控制会更加严格，这时候设置合理的超时时间可以有效避免半开链接。

     一般超时时间，dbcp主要是minEvictableIdleTimeMillis(空闲链接) , removeAbandonedTimeout(链接泄漏)。可以见前面的参数解释。



别一篇


使用数据库连接池时，免不了会遇到断网、数据库挂掉等异常状况，当网络或数据库恢复时，若无法恢复连接池中的连接，那必然会是一场灾难。

关于dbcp的自动重连配置，网上相关的资料也不少，通过以下资料，并对照官方文档中的参数说明，大致能了解各项配置的含义，我就不冗诉了，本文的目的主要是对问题排查的经过做个简单的记录。
参考资料：

  • 解读dbcp自动重连那些事
  • 官方文档

测试环境：
  • dbcp版本——1.4
  • 数据库——postgresSQL 9.10（简称pg）
  • 本地(以下称为client)操作系统及数据库服务器(以下称为server)操作系统均为linux
  • server位于内网环境，client需要通过vpn或网线直连内网才能访问数据库

首先模拟的是断网的情况
在本地测试dbcp的重连配置时，发现断网后，连接池无法重建连接，分别试过testOnBorrow和testWhileIdle两种validate方式，都没能解决，现象如下：
1. 正常启动应用，在server端通过"select * from pg_stat_activity"查看连接数，会有initialSize个来自client的IDLE连接。——正常
2. 在client端执行各种查询操作，连接数保持不变，且在server端的db log中能看到validate query。——正常
3. 手动切断vpn，client与server断开，查询无法返回结果；然后重连，再次查看连接数，连接数仍保持不变，且连接的创建时间为断网前，即是说连接池认为之前的连接仍然有效，没有销毁旧连接&创建新连接。
4. 此时在应用中执行各种查询操作，均无响应，等待一段时间后（分钟级），超时抛出异常：
Caused by: org.postgresql.util.PSQLException: An I/O error occured while sending to the backend.
Caused by: java.net.SocketException: Connection timed out.
5. 继续通过"select * from pg_stat_activity"查看连接数，隔一段时间后，连接消失。

问题：断网后，仍留在线程池内的连接是否有效？若有效，为什么网络恢复后查询无响应？若无效，为何线程池没有发现并重新创建有效连接？
排查过程：
1.重连vpn后，通过netstat查看client至server的连接
Java代码  
  1. sudo netstat -antop | grep :5432  | grep java  
注：5432为pg端口，grep java是为了过滤client上的其他形式的连接。
发现连接数和在server端看到的连接数一致，且均为ESTABLISH状态。
2. 但在client上执行查询时，通过tcpdump查看client发往server的tcp请求，并无任何请求产生。
Java代码  
  1. sudo tcpdump -s 65535 -X -i eth0 host xxx.xxx.xxx  
可见当前线程池中的连接实际上已经失效了，但dbcp仍认为它是有效的，因此仍在尝试用旧连接访问数据库，直至网络超时。

于是，开始怀疑是vpn的问题，将client接上网线直连内网后，再次重试上述步骤，只是把断网的方式由切断vpn换成了拔网线，发现这次使用断网前的连接能够正常访问数据库，于是断定是vpn的问题，猜测是重连vpn后，虽然client端ip没有变，但路由的路径已经变了，之前的连接无法复用，但dbcp并不知道。对网络细节不是太熟悉，就不多加揣测了。

接下来模拟数据库断开client连接的情况
由于pg采用的是进程模型，与数据库建立的每一个连接都是单独的一个进程，故尝试采用kill进程的方式模拟数据库断开连接。
预期的结果是：kill掉一个连接进程后，dbcp通过validate query发现该连接失效，将销毁该连接并重新创建新连接。
但实际情况确是：kill掉一个连接后，所有连接全部被销毁。
问题：究竟是数据库还是dbcp销毁了所有连接?
排查过程：
熟悉pg的同事认为pg之所以采用进程模型，就是为了避免连接之间的影响，因此不可能发生kill一个连接，其他连接也被销毁的情况。在这个理论前提下，问题就变得很诡异，因为dbcp的validate肯定是针对一个连接的，也不可能会在validate一个连接失效的情况下销毁所有连接，于是越想越偏，甚至开始怀疑是pg的jdbc driver有问题，最终放弃了深究。
但我总觉得有点不太对劲，于是推翻之前的前提，开始怀疑是pg销毁了所有连接。于是，在使用连接池的应用之外，通过pg的数据库客户端psql连接db，这就建立了一个与dbcp无关的连接，接着继续在server端kill了一个连接池中的连接，继而发现psql创建的连接也被销毁了，这就能确定是pg在销毁连接，因为dbcp不可能控制自身范围之外的连接。
后来才知道，pg之所以会这么做，是因为我们kill连接时使用的是kill -9（简称9杀），9杀太过粗暴，pg会重启很多内部进程，以保证所有进程正常，之前的连接也将会丢失，换用普通的kill命令，则不会发生以上情况。可见9杀很多情况下是十分危险的，试想一个线上db，若是9杀一个连接，后果不堪设想。。。

总结
说是dbcp问题排查，但大家可以看到最终问题的根源都跟dbcp没有什么关系。实际工作中的很多问题，关联的因素众多，需要有各方面的知识储备才能找到真正问题根源，否则就会把问题归结到一个自己不太了解的领域。
另外，看到dbcp基本配置和重连配置这篇文章中对连接池重连有两句不错的总结，引用一下：
引用
1. 数据库意外重启后，原先的数据库连接池能自动废弃老的无用的链接，建立新的数据库链接
2. 网络异常中断后，原先的建立的tcp链接，应该能进行自动切换


最后附上测试使用的dbcp配置。
testOnBorrow配置：
Xml代码  
  1. <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">  
  2.         <property name="driverClassName" value="${jdbc.driver}" />  
  3.         <property name="url" value="${jdbc.url}"/>  
  4.         <property name="username" value="${jdbc.user}" />  
  5.         <property name="password" value="${jdbc.passwd}" />  
  6.         <property name="removeAbandoned" value="true"/>  
  7.           <property name="initialSize" value="10" />  
  8.           <property name="maxIdle" value="10" />  
  9.           <property name="minIdle" value="10" />  
  10.            <property name="maxActive" value="30" />  
  11.            <property name="maxWait" value="30000" />  
  12.            <property name= "testWhileIdle" value="false" />  
  13.         <property name= "testOnBorrow" value="true" />  
  14.         <property name= "testOnReturn" value="false" />  
  15.         <property name= "validationQuery" value="select 1" />  
  16.         <!-- <property name= "validationQueryTimeout" value="1" /> 配置已失效-->  
  17.     </bean>  
testWhileIdle配置：
Xml代码  
  1. <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">  
  2.         <property name="driverClassName" value="${jdbc.driver}" />  
  3.         <property name="url" value="${jdbc.url}"/>  
  4.         <property name="username" value="${jdbc.user}" />  
  5.         <property name="password" value="${jdbc.passwd}" />  
  6.         <property name="removeAbandoned" value="true"/>  
  7.           <property name="initialSize" value="10" />  
  8.           <property name="maxIdle" value="10" />  
  9.           <property name="minIdle" value="10" />  
  10.            <property name="maxActive" value="30" />  
  11.            <property name="maxWait" value="30000" />  
  12.            <property name= "testWhileIdle" value="true" />  
  13.         <property name= "testOnBorrow" value="false" />  
  14.         <property name= "testOnReturn" value="false" />  
  15.         <property name= "validationQuery" value="select 1" />  
  16.         <!-- <property name= "validationQueryTimeout" value="1" /> 配置已失效-->  
  17.         <property name= "timeBetweenEvictionRunsMillis" value="30000" />  
  18.         <property name= "numTestsPerEvictionRun" value="30" />  
  19.         <property name="minEvictableIdleTimeMillis" value="1800000" />  
  20.     </bean>  
注：testOnBorrow只会发现当前连接失效，再创建一个连接供当前查询使用，而testWhileIdle会定时校验numTestsPerEvictionRun个连接，只要发现连接失效，就将其移除再重新创建。

0 0
淘宝流量如何提升 淘宝流量如何提升
原创粉丝点击
热门IT博客
java人才培训中心java人才培训中心
mysql创建学生信息表mysql创建学生信息表
sql注入攻击步骤
樱井知香番号作品截图
淘宝 2.8mm 监控镜头
西电校园网网络认证
扫题软件
外研社杯阅读大赛知乎
md5与sha1算法
mac版电脑能下淘宝
新版淘宝联盟自己购买
主成分分析软件
顶级域名带几个二级
mysql 5.7 发布时间
外文数据库有哪些
node.js买什么书
摩拜单车在上海的数据
linux 解压rar文件命令
php pack
饥荒辅助软件
热门问题 老师的惩罚 人脸识别 我在镇武司摸鱼那些年 重生之率土为王 我在大康的咸鱼生活 盘龙之生命进化 天生仙种 凡人之先天五行 春回大明朝 姑娘不必设防，我是瞎子 新会市 新会站 广东新会 新会景点 新会招聘 新会楼盘 新会江门 新会在哪里 新会陈皮功效 新会小鸟天堂 新会古兜温泉 新会陈皮制作技艺 新会古兜温泉旅游 新会陈皮产区排名 新会古兜温泉旅游度假村旅游 新会邮政编码 新会人民医院 新会陈皮价格 新会旅游景点 新会厨师培训中心 楚留香新传 黄蓉新传 高衙内新传 阿旺新传 汉献帝新传 刺客新传 武松新传 郭嘉新传 爱奴新传 玉鼎新传 霸王新传 黄飞鸿新传 武大郎新传 南明新传 荆轲新传 老扒新传 杨过新传 鬼厉新传 西游新传 新传 贾宝玉新传

程序博客网，程序员的互联网技术博客家园。csdn论坛精品 msdn技术资料都在这里