Open 15271944243 opened 2 years ago
wenshao
commented
2 years ago maxEvictableIdleTimeMillis指定最大使用时长，对分布式数据库比，如阿里云的PolarDB-X（DRDS）/AnalyticDB这样的数据库做优雅的滚动升级比较有用。对应的还有一个phyMaxUseCount是指定最大使用次数，这个对分布式数据库的负载均衡比较好。
testWhile在遇到链接已经失效的时候，会导致单次请求延时变长。
15271944243
commented
2 years ago 感谢大佬的回复，还是麻烦大佬能够详细解释下，为什么 maxEvictableIdleTimeMillis 对如阿里云的PolarDB-X（DRDS）/AnalyticDB这样的数据库做优雅的滚动升级比较有用，如果对于普通的 mysql 分库分表，maxEvictableIdleTimeMillis 与 minEvictableIdleTimeMillis 在功能上是不是没什么区别？
kimmking
commented
2 years ago 还有一个解释的角度： 1、部分参数是基于getConnection时的主动检查； 2、部分参数是基于task/shrink的异步被动检查。
CodeRusher
commented
1 year ago 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 已经有了保活机制，这里为什么还要再弄一个？