开发公司年度总结报告南宁seo网络优化公司
最近发现生产环境经常有数据库连接超时的问题，排查发现是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=60000connectTimeout为建立数据库连接的超时时间； 如果不设置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特意改成毫秒(可以看下面的代码对比)。虽然从统一性角度来说，确实用毫秒比较合理。但是对使用者来说，从低版本升级到高版本，参数配置突然就有问题了。真的很不友好
