光明做网站,南京app开发公司定制,网络系统管理与维护电大考试题,抚顺网络推广一、前言
连接池的用途实际上有过开发经验的朋友都已经比较清楚了#xff0c;当资源对象的创建/销毁比较耗时的场景下#xff0c;可以通过池化技术#xff0c;达到资源的复用#xff0c;以此来减少系统的开销、增大系统吞吐量#xff0c;比如数据库连接池、线…一、前言
连接池的用途实际上有过开发经验的朋友都已经比较清楚了当资源对象的创建/销毁比较耗时的场景下可以通过池化技术达到资源的复用以此来减少系统的开销、增大系统吞吐量比如数据库连接池、线程池、Redis 连接池等都是使用的该方式而我们在开发场景中使用较为广泛的 Jedis 就是使用了 GenericObjectPool 作为它底层的连接池实现。
二、原理概述
图示 BorrowObject
业务模块通过 BorrowObject 方法从空闲连接队列中获取空闲连接最长会等待 maxWaitMillis 毫秒如果拿不到则走 Create。
ReturnObject
把连接重新放回到 IdleObjects 队列中。
类结构 Jedis里如何使用的
一般情况下我们在 Spring Boot 应用中会通过 Spring-Data-Redis 来使用 Redis而在业务层会通过 RedisTemplate 来进行 Redis 的操作但是 RedisTemplate 是怎么来的呢可以看到当我们引入 Spring-Data-Redis 时就会引入 RedisAutoConfiguration这个 AutoConfiguration 定义了当我们存在 Jedis 的配置时且不存在 RedisTempalte 的 Bean 实例时会自动创建 Bean核心代码如下图。 而 RedisConnectionFactory 的其中一个实现就是 JedisConnectionFactory其中就包含了 Pool。 而 Pool 本身内部就能看到我们真正的主角。 捋一下其中的关系我们常用的 Spring-Data-Redis 的 Jedis 实现最终是通过以下的层级结构来使用 GenericObjectPool 的。 三、深入分析
参数说明
如上述类结构所示GenericObjectPool 都是在 GenericObjectPoolConfig 或 BaseObjectPoolConfig 中进行配置相关参数的其中核心参数以及默认值如下 上图对这些参数按颜色进行了一个归类 这里需要注意的是虽然 GenericObjectPool 支持我们配的参数较多但是 Spring-Data-Redis 将这部分参数收敛了具体可供我们修改的只有表格上面的这部分内容其他参数有一部分在 JedisPoolConfig 类中继承了 GenericObjectPoolConfig 进行了修改比如 Spring-Data-Redis 就修改了以下参数的默认值。 testWhileIdletrue minEvictableIdleTimeMillis60000 timeBetweenEvictionRunsMillis30000 numTestsPerEvictionRun-1 核心方法
本文只会针对方法的一些核心链路进行说明如想知道更多细节针对源码解析的可以在网上搜索其他相关文章或是到我的参考链接里进行翻看。
BorrowObject
超时时间怎么用的
该方法用于从连接池中获取一个空闲对象它有可能是从空闲池中直接获取的或是直接创建出来的如果第一次从空闲对象中没有获取到会走创建后重新获取此时如果对象池目前配置的 BlockWhenExhaustedtrue那么就会受 maxWaitMillis 参数所配置的超时时间所控制如果超过了超时时间都没拿到一个空闲的对象则会直接抛出异常。
testOnBorrow 和 testOnCreate 的使用场景
当获取到一个对象后由于对象池中往往存放的是诸如数据库连接、Redis 连接等创建时较为耗时的资源但是因为连接本身是复用的如果 MySQL/Redis Server 端如果因为某些原因断开/释放了该链接那么此时拿到的对象就是个无效的对象因此在 borrowObject 阶段会判定如果 testOnBorrowtrue || (create testOnCreatetrue) 就会走到 factory.validateObject 这里如何进行 validateObject 的是由上层使用对象池的场景所决定的比如在 Jedis 场景中会向 Redis Server 发送一个 Ping 命令如果 Server 返回了 Pong则认为该连接仍然有效可以给业务层使用。
但是
线上环境千万不要配置 testOnBorrowtrue 或是 testOnCreatetrue。
每个对象的获取都需要先校验再拿会大大增加单次请求的 RT。
ReturnObject
testOnReturn 的使用场景
实际上 testOnReturn 的使用场景与上述 borrowObject 时的 testOnBorrow 是类似的只是testOnReturn就是一个归还对象的操作。同理线上千万不要配置 testOnReturntrue。
什么时候归还什么时候销毁
对象池中维护了一个结构为 LinkedBlockingDeque名为 IdleObjects 的对象用于维护空闲对象队列且是否归或销毁的判断逻辑如下
final int maxIdleSave getMaxIdle();
if (isClosed() || maxIdleSave -1 maxIdleSave idleObjects.size()) {...销毁对象
}else{...返还至idleObjects
}如果
对象池已经关闭(只要是程序在运行且正常使用不会关闭
或
配置了 maxIdle 且空闲对象列表数量 maxIdle
则对象会被销毁否则对象会重新回到 IdleObjects 中。
四、内部机制
Evict(定期驱逐/保活机制)
周期怎么定
当 timeBetweenEvictionRunsMillis 配置 0 时在 GenericObjectPool 所继承的基类中会启一个周期性执行的线程它的执行周期就是 timeBetweenEvictionRunsMillis 的值。
为什么要驱逐
当空闲对象过多对于客户端或服务端的 TCP 连接维护来讲本身就是一个开销因此需要有一个规则当有一些对象实在太空闲了就把它们踢掉。
哪些对象应该被驱逐
首先会从空闲对象列表中挑选出一部分对象而这个挑选过程本身也有一个规则它受 numTestsPerEvictionRun 参数控制。 当 numTestsPerEvictionRun0会挑选出 numTestsPerEvictionRun 数量的空闲连接进行检查。 当 numTestsPerEvictionRun0 时首先会对 numTestsPerEvictionRun 取绝对值再然后挑选出空闲数量 /numTestsPerEvictionRun 绝对值的数量进行检查举个例子如果 numTestsPerEvictionRun-2就会挑选出一半进行检查。 驱逐检查怎么做
本身驱逐检查的实现方式是支持自定义的也就是 evictionPolicy 参数但是往往只会选择用默认的实现也就是 DefaultEvictionPolicy它的驱逐检查策略如下
if ((config.getIdleSoftEvictTime() underTest.getIdleTimeMillis() config.getMinIdle() idleCount) ||config.getIdleEvictTime() underTest.getIdleTimeMillis()) {return true;
}
return false;underTest 为被检查对象当存在以下场景时满足驱逐检查规则会触发驱逐。 underTest 的空闲时间 softMinEvictableIdleTimeMillis 且当前空闲对象数量 minIdle 或 underTest 的空闲时间 minEvictableIdleTimeMillis。 Tips有一些好奇的同学可能会问对象的空闲时间是怎么算的 池中的对象本身会维护一个 lastReturnTime 的时间戳它会随着对象每一次 returnObject 时进行更新当获取对象空闲时间时只要它还是在空闲对象中那么用当前时间戳 -lastReturnTime 就是认为该对象的空闲时间。 驱逐与保活的关系是怎么样的
由于前面提到过不能配置 testOnBorrow 和 testOnReturn那么如果 Server 端的链接直接断开了怎么能保证池中对象的有效性呢如果让调用端调用时再触发会不会太晚了呢这时候就有个参数 testWhileIdle当此参数打开时就代表会在对象空闲时进行对象可用性检查具体代码如下
if (evict) {destroy(underTest);destroyedByEvictorCount.incrementAndGet();
} else {if (testWhileIdle) {try {factory.activateObject(underTest);} catch (final Exception e) {destroy(underTest);destroyedByEvictorCount.incrementAndGet();}}
}这里隐掉了一些相关的非核心逻辑这里可以看到 testWhileIdle 的保活机制实际上和 evict 是配套使用的如果被检查对象需要被驱逐也就是 evicttrue则会直接 destory 对象否则它会判定 testWhileIdle 的状态此时如果 testWhileIdletrue那么就会激活一下对象具体激活的方式是由使用对象池的上层工厂所决定的。
Test(检查机制)
本身 GenericObjectPool 为了保证在池子中的对象有效性会允许上层分别在几个节点进行对象的有效性检查分别是 testOnBorrow、testOnReturn、testOnCreate。 这几个基本看名字就知道是什么意思了在前面讲 borrowObject 和 returnObject 的时候也有提到还有一个相对比较特别的是 testWhileIdle。 该参数目的是为了对象在空闲期间可以进行检查而它的触发实际上是和 evict(定期驱逐机制)联合起来进行使用的。
Abandoned(抛弃机制)
实际上在提到配置参数、BorrowObject 时还有一个机制称之为 Abandoned由于本文的契机是因为 Jedis 的问题分析所写而 Jedis 连接池并不支持配置 Abandoned所以本文暂不做解析或者感兴趣的可以自己到上面讲的源码路径去看一下本身这个机制的理解也不是特别复杂。
五、排障方式
本身 GenericObjectPool 默认会把自己的一些参数通过 JMX 的方式进行注册那么我们可以通过 Jvisualvm 进行查看或是通过 Arthas输入如下命令
mbean org.apache.commons.pool2:typeGenericObjectPool,namepool-redisConnectionFactory可以获取到对象池当前的一些属性如下图 其中对于优化比较有用的就是 CreatedCount创建对象的数量、DestoryedCount对象销毁的对象、DestoryedByEvictorCount因为驱逐机制而被销毁的对象数量。
六、总结
上述文章以 Jedis 为引分析了 GenericObjectPool 连接池的底层原理以及 Jedis 是如何使用该连接池的并且结合了 Arthas 分享了一个简单的排障方式实际上如果知道了 GenericObjectPool 连接池的原理其他连接池也是大同小异本文希望抛砖引玉带大家对于连接池的底层实现有个基本概念相信以后遇到此类问题也会有分析的思路不再迷茫~
*文/will
本文属得物技术原创更多精彩文章请看得物技术官网
未经得物技术许可严禁转载否则依法追究法律责任
