druid毗连池参数设置

迩来发现生产情况常常有数据库毗连超时的题目，排查发现是druid毗连池参数设置不公道导致

总结题目如下：
为了防止僵尸毗连，k8s ipvs做了毗连超时限定，如果TCP毗连闲置高出900s(15分钟)，客户端再实验通过这个毗连去发起哀求，数据包颠末防火墙会被直接扬弃掉，无法到达服务端。
从客户端的角度来看，就是发送了数据包之后，壅闭等候服务端相应，但是很显着永久都不大概得到相应，天然就超时了。
以是在设置毗连池的时间，须要制止毗连长期闲置不开释；大概如果须要长期保存一些毗连不开释，要有对应的毗连保活机制

druid毗连池设置属性先容：https://github.com/alibaba/druid/wiki/DruidDataSource%E9%85%8D%E7%BD%AE%E5%B1%9E%E6%80%A7%E5%88%97%E8%A1%A8

下面先容一下对我们影响较大的一些参数：

参数名	发起值	参数阐明
connectionProperties 复制代码		差别数据库设置属性值有差别，比如pg的loginTimeout单元是秒（新版druid也是毫秒），MySQL是毫秒 pg发起设置： druid.stat.mergeSql=true;druid.stat.slowSqlMillis=5000;loginTimeout=5;connectTimeout=5;socketTimeout=60 注意：新版druid(1.2.17开始)要求配置druid.stat.mergeSql=true;druid.stat.slowSqlMillis=5000;loginTimeout=5000;connectTimeout=5000;socketTimeout=60000 MySQL建议配置： 复制代码 druid.stat.mergeSql=true;druid.stat.slowSqlMillis=5000;loginTimeout=5000;connectTimeout=5000;socketTimeout=60000 connectTimeout为建立数据库连接的超时时间； 如果不设置loginTimeout，会在当前线程直接去建立连接；设置了loginTimeout，则会创建异步线程去建立连接。推测是为了防止底层系统阻塞，导致上层应用线程挂死； socketTimeout即readTimeOut，最大sql执行时间 复制代码
maxWait	5000	获取毗连时最大等候时间，单元毫秒。默认-1 这个只是从毗连池单次获取毗连的等候时间，真正的创建数据库毗连的超时时间，由上面的loginTimeout、connectTimeout决定 注意不能把maxWait明白为应用获取毗连的最大耗时，由于这里只是单次从毗连池获取毗连的等候时间，现实获取毗连的实现是一个无穷循环：获取毗连 → 校验毗连 → 校验不通过则继承获取新的毗连直到校验通过 以是我们把maxWait和validationQuery都设置为5s的时间，出现了现实获取毗连耗时10s的情况，这是由于两次获取的毗连都是僵尸毗连，实行validationQuery的时间超时失败，第三次才获取到正常的毗连
maxActive	20~50 根据应用具体情况设置，不发起设置太大	最大毗连池数量
minIdle	0~5	最小毗连池数量 如果没有设置maxEvictableIdleTimeMillis，则minIdle应该设置为0
initialSize	0~5	初始化时创建物理毗连的个数
timeBetweenEvictionRunsMillis	30000	有两个寄义： 1) Destroy线程会检测毗连的隔断时间，如果毗连空闲时间大于即是minEvictableIdleTimeMillis则关闭物理毗连。 2) testWhileIdle的判断依据，具体看testWhileIdle属性的阐明
minEvictableIdleTimeMillis	60000	毗连保持空闲而不被驱逐的最小时间， 高出minIdle的毗连，空闲时间大于这个值会被驱逐
maxEvictableIdleTimeMillis	120000	毗连保持空闲而不被驱逐的最大时间，默认7小时 minIdle的毗连，空闲时间大于这个值会被驱逐 之前就是由于这个值没有设置，且minIdle大于0，以是毗连不绝不会被驱逐
validationQuery	SELECT 1	用来检测毗连是否有用的sql 如果validationQuery为null，testOnBorrow、testOnReturn、testWhileIdle都不会起作用
validationQueryTimeout	5	单元：秒，检测毗连是否有用的超时时间，根据设置选择利用发送ping大概实行validationQuery sql的方式举行毗连校验 之前数据网关接口耗时30s多一点，其缘故原由就是这个值设置为30s
testWhileIdle	true	申请毗连的时间检测，如果空闲时间大于timeBetweenEvictionRunsMillis，实行validationQuery检测毗连是否有用
testOnBorrow	false	申请毗连时实行validationQuery检测毗连是否有用，做了这个设置会低落性能
testOnReturn	false	归还毗连时实行validationQuery检测毗连是否有用，做了这个设置会低落性能
keepAlive	true	毗连池中的minIdle数量以内的毗连，空闲时间高出minEvictableIdleTimeMillis，则会实行keepAlive操纵 这个参数大概不会见效，最好不要依靠它来做毗连保活
poolPreparedStatements	false	是否缓存preparedStatement，也就是PSCache。PSCache对支持游标的数据库性能提升巨大，比如说oracle。在mysql下发起关闭。 pg也发起关闭
connectionErrorRetryAttempts	1	异步创建毗连的线程，在创建毗连失败后会会举行计数，当errorCount小于即是connectionErrorRetryAttempts时会立即举行失败重试。当errorCount大于connectionErrorRetryAttempts时，默认情况会sleep timeBetweenConnectErrorMillis(默认500ms)后再举行重试
timeBetweenConnectErrorMillis	500	默认500ms 见上面connectionErrorRetryAttempts释义
breakAfterAcquireFailure	false	注意这个值千万不要设为true 设为true，一旦创建数据库毗连失败，创建毗连的异步线程就会停止，导致的结果就是，偶然的网络颠簸，会导致应用后续不绝获取毗连失败，纵然网络规复正常 拜见：https://github.com/alibaba/druid/issues/2862

这里特殊想吐槽下connectionProperties参数的设置，pg的设置原来单元是秒，1.2.17特意改成毫秒(可以看下面的代码对比)。固然从同一性角度来说，确实用毫秒比力公道。但是对利用者来说，从低版本升级到高版本，参数设置忽然就有题目了。真的很不友爱