HikariCP的ConnectionTimeout应该配多少

ConnectionTimeout
This property controls the maximum number of milliseconds that a client (that’s you) will wait for a connection from the pool. If this time is exceeded without a connection becoming available, a SQLException will be thrown. Lowest acceptable connection timeout is 250 ms. Default: 30000 (30 seconds)
此属性控制客户端等待来自连接池的连接的最大毫秒数。如果超过这个时间而没有连接可用，将抛出SQLException。最低可接受的连接超时时间是250毫秒。默认值:30000(30秒)

以上为HikariCP的官方解释
我建议配置小于接口超时时间

事故

上周，我们的线上服务发生了一次事故，导致应用挂掉，多次重启无果，最终回滚。
后来根据一系列的监控发现是应用线程池满了，导致健康检查失败，应用被摘掉。

还原

我们的请求进到应用，会先由dubbo线程池处理，拿到数据库连接池，查询到数据，一次请求结束

那么一次请求的耗时由哪些部分构成

依照上述背景，假设在200并发时出现慢查询，且
慢查询耗时无限大 = n
业务逻代码耗时 = z
ConnectionTimeout = x
接口超时时间 = y

1. x > y
   50个数据库连接被慢查询占用，将会有50个dubbo线程等待查询结束耗时（n + z），其余150个dubbo线程将会耗时（n+z+x），因为x>y 且n无限大，所以这200个请求，都会收到dubbo框架的超时告警，dubbo客户端会结束这次请求（不配置重试的话），然而在服务端，这200个线程因为依旧在工作有50个在等待查询结束，所以不会被回收，150个在等待连接池资源知道事件(z+x)后抛出连接池异常，所以在(z+x)的时间内请求将获取不到线程而被拒绝，此时服务处于不可用状态
2. x <y
   50个数据库连接被慢查询占用，将会有50个dubbo线程等待查询结束耗时（n + z），其余150个dubbo线程将会耗时（n+z+x），因为x<y，所以在报出接口超时前，服务端会先收到获取数据库连接池的异常，这时候可以做相应的业务异常处理响应给客户端，也可以根据异常发送告警，而后会释放dubbo线程，服务仍可用

综上，我认为 ConnectionTimeout小于接口超时时间更合理，可以有效的保护服务的可用性