Open 15271944243 opened 2 years ago
maxEvictableIdleTimeMillis指定最大使用时长,对分布式数据库比,如阿里云的PolarDB-X(DRDS)/AnalyticDB这样的数据库做优雅的滚动升级比较有用。对应的还有一个phyMaxUseCount是指定最大使用次数,这个对分布式数据库的负载均衡比较好。
testWhile在遇到链接已经失效的时候,会导致单次请求延时变长。
感谢大佬的回复,还是麻烦大佬能够详细解释下,为什么 maxEvictableIdleTimeMillis 对如阿里云的PolarDB-X(DRDS)/AnalyticDB这样的数据库做优雅的滚动升级比较有用,如果对于普通的 mysql 分库分表,maxEvictableIdleTimeMillis 与 minEvictableIdleTimeMillis 在功能上是不是没什么区别?
还有一个解释的角度: 1、部分参数是基于getConnection时的主动检查; 2、部分参数是基于task/shrink的异步被动检查。
minEvictableIdleTimeMillis: 如果有连接空闲时间超过minEvictableIdleTimeMillis,并且这些连接的数量超过了minIdle,则超过的这部分的连接会被回收 maxEvictableIdleTimeMillis:空闲时间只要超过了maxEvictableIdleTimeMillis,则被回收;和上面minEvictableIdleTimeMillis的区别是,没有minIdle的限制
请教各位, 我看早期版本(例如 1.0.12) 此时只有 minEvictableIdleTimeMillis, 之后 1.0.18 版本,加入了 maxEvictableIdleTimeMillis, 再之后 1.0.28版本,加入了 keepAliveBetweenTimeMillis。
是为什么要加入 maxEvictableIdleTimeMillis、keepAliveBetweenTimeMillis,它们是在什么场景下解决了什么样的问题呢? 仅使用 minEvictableIdleTimeMillis 一个不行吗 ?
1.0.18 版本的升级说明里说,加入了 maxEvictableIdleTimeMillis,是为了解决mysql服务器8小时关闭连接的问题,那 minEvictableIdleTimeMillis 不行吗?
1.0.28 版本的升级说明里说,加入 keepAliveBetweenTimeMillis,是在使用testWhileIdle的情况下,不能满足某些场景需要保活连接的需求,那是什么样的场景需要呢,而且 tcp 已经有了保活机制,这里为什么还要再弄一个?