前言
在上一篇文章中，咱们介绍了弹性数据库连贯生效的背景，并探讨了HikariCP连接池探活策略的相干内容。在本文中，咱们将会持续探讨另一个线上罕用的连接池——Druid，并为您介绍如何在应用Druid时实现最佳实际的弹性数据库连接池探活策略。
Druid
Druid的版本迭代更新比拟快，同时探活配置的参数也比拟多，这导致即便是雷同的参数在不同的版本中达到的成果也可能不一样。但与探活相干的逻辑实现只存在源码里的两个函数里， 咱们先列举一下跟Druid探活相干的参数，在具体看一下源码的实现对这些参数的应用。日后咱们在开发中遇到配置探活不失效的状况下，能够看一下对应版本源码来判断本人的探活是否配置正确。
上面是与Druid探活相干的参数：
| 参数名称 | 阐明 | 默认值 |
|---|---|---|
| initialSize | 初始化时建设物理连贯的个数。初始化产生在显示调用init办法，或者第一次getConnection时。 | 0 |
| minIdle | 最小连接池数量。 | 0 |
| maxActive | 最大连接池数量。 | 8 |
| testOnBorrow | 申请连贯时执行validationQuery配置的SQL检测连贯是否无效，做了这个配置会升高性能。 | false |
| testOnReturn | 偿还连贯时执行validationQuery检测连贯是否无效，做了这个配置会升高性能。 | false |
| testWhileIdle | 倡议配置为true，不影响性能，并且保障安全性。在连接池中申请连贯的时候检测，如果闲暇工夫大于timeBetweenEvictionRunsMillis，执行validationQuery检测连贯是否无效。 | 大多数版本为True |
| timeBetweenEvictionRunsMillis | 1) Destroy线程会检测连贯的间隔时间，每隔这个值的工夫就会执行一次DestroyTask。 2) testWhileIdle的判断根据，具体看testWhileIdle属性的阐明。 | 大多数版本是1分钟 |
| keepAlive | 连接池中的minIdle数量以内的连贯，闲暇工夫超过minEvictableIdleTimeMillis，则会执行探活操作此参数在1.0.28以上的版本才反对 具体阐明参考官网文档。 | false |
| keepAliveBetweenTimeMillis | 配合keepAlive应用在低版本不反对，如果闲暇工夫小于timeBetweenEvictionRunsMillis但大于keepAliveBetweenTimeMillis扔执行探活操作 | 大多数版本是2分钟 |
| validationQuery | 用来检测连贯是否无效的sql，要求是一个查问语句。 | select 1 |
| validationQueryTimeout | 单位：秒，检测连贯是否无效的超时工夫。底层调用jdbc Statement对象的void setQueryTimeout(int seconds)办法 | |
| minEvictableIdleTimeMillis | 连贯闲暇工夫大于该值时敞开闲暇连贯大于minIdle的连贯，相似hikaricp的idleTimeout | 30分钟 |
| maxEvictableIdleTimeMillis | 连贯闲暇工夫大于该值时不论minIdle都敞开该连贯，相似hikaricp的maxlifetime（低版本不反对） | 7小时 |
Druid的探活次要有以下两个函数来实现：
- com.alibaba.druid.pool.DruidDataSource#getConnectionDirect
getConnectionDirect是每次从连接池中取连贯时会被调用的函数。咱们从上面的代码中能够看出，如果testOnBorrow为true，则每次获取连贯之前都会检测连贯是否无效。如果testOnBorrow为false且testWhileIdle为true，则须要判断连贯的闲暇工夫是否超过timeBetweenEvictionRunsMillis设置的值，如果超过则进行探活检测。生效的连贯会被抛弃，并且会补充到连接池的minIdle数量。timeBetweenEvictionRunsMillis在大多数版本中的默认值为1分钟。只有这个值设置的工夫小于十分钟，并且保障testWhileIdle开启，就能保障拿不到网关敞开的生效连贯。
在不反对keepalive的低版本中，只能依附testOnBorrow或testWhileIdle来进行探活。倡议配置testWhileIdle来进行探活。在高并发的场景下，这种形式的性能耗费会更小一些。
- com.alibaba.druid.pool.DruidDataSource#shrink(boolean, boolean)
在上面的代码中咱们能够看出，shrink办法是在DestroyTask线程的run办法中调用的，用于销毁连接池中的连贯。如果timeBetweenEvictionRunsMillis大于0，则每隔这个工夫距离就会调用destroyTask.run(boolean, boolean)办法，即执行shrink办法。
从下面的代码中能够看出，shrink办法会应用keepAlive参数。须要留神的是，在不同版本的Druid中，keepAlive参数的反对和实现逻辑可能不同。官网倡议在应用keepAlive参数时，应该应用1.1.21以上的版本。只管官网文档中阐明了闲暇工夫超过minEvictableIdleTimeMillis，就会执行探活操作，然而在高版本中，这个探活操作的执行工夫也受到了keepAliveBetweenTimeMillis参数的影响。因而，在高版本中，如果想要正确地应用keepAlive参数，就须要理解其在具体版本中的实现逻辑。
上面代码是1.1.10和1.1.21版本中对于shrink办法的源码比照：
首先看一下1.1.10版本的源码，它首先会判断连贯闲暇工夫是否大于minEvictableIdleTimeMillis，如果是，则接下来进行第二步的判断：是否是多于minIdle的闲暇连贯。如果是，就将这些连贯退出到驱赶连贯的数组中，以便进行后续的驱赶操作。如果不是，就再次判断连贯闲暇工夫是否大于maxEvictableIdleTimeMillis，如果是，则将这些连贯退出到驱赶连贯的数组中。如果也不是，则进行最初的判断：是否开启了keepAlive配置。如果开启了，就将这些连贯退出到保活连贯数组中，以进行后续的探活操作。
在1.1.21版本中，shrink办法的总体逻辑与1.1.10版本相似，然而新增了一个名为keepAliveBetweenTimeMillis的参数。这个参数决定了应用keepAlive进行探活的工夫距离，其默认值为2分钟，keepalive开启且闲暇工夫大于这个值会进行探活。
另一个不同点是，在进行探活操作时，1.1.10版本仅会敞开有效的连贯，但1.1.21版本则更进一步，除了敞开有效连贯外，还会主动增加连贯以达到minIdle的最小连接数。
1.1.10 1.1.21
总结，druid的探活参数在1.0.28版本之前没有定时的探活性能只能在每次拿到连贯前进行检测是否无效，倡议配置testWhileIdle为true在高并发状况下不会太影响性能，如果对可用性要求高的能够开启testOnBorrow，以在每次获取连贯时检测连贯的有效性。在高版本中能够用keepAlive参数对连贯进行保活。针对线上应用Druid连接池的利用倡议应用反对keepAlive的1.1.21或者更高版本。
JED配置模版：
Druid1.1.10
<propertyname="testWhileIdle"value="true"/> <propertyname="validationQuery"value="SELECT 1"/> <propertyname="timeBetweenEvictionRunsMillis"value="30000"/> <propertyname="minEvictableIdleTimeMillis"value="300000"/><propertyname="keepAlive"value=true/>此版本反对keepAlive能够配置minEvictableIdleTimeMillis工夫小于10分钟，可能高效的进行探活避免网关敞开连贯。
Druid1.1.9
同1.1.10
Druid1.0.9
<propertyname="testWhileIdle"value="true"/> <propertyname="validationQuery"value="SELECT 1"/> <propertyname="timeBetweenEvictionRunsMillis"value="30000"/> <propertyname="minEvictableIdleTimeMillis"value="300000"/>此版本不反对keepAlive只能在获取连贯对象的时候检测，对可用性高的也能够开启testOnBorrow。
作者：京东批发 王雷鑫
起源：京东云开发者社区 转载请注明起源