没有可用连接时的 HikariCP 行为答案

【问题标题】：HikariCP behavior when no connection is available没有可用连接时的 HikariCP 行为
【发布时间】：2019-10-10 21:00:00
【问题描述】：

我注意到即使在数据库关闭时，池中实际上没有可用的连接，Hikari CP 仍然等待连接超时到期，然后再向客户端发送异常。

我同意当数据库可用时这是可取的，但在我的情况下，我希望池在没有可用连接时发送异常之前不要等待。

原因是数据库本身在不到 2 毫秒的时间内回答，所以我每秒可以处理数千个事务，但是当没有可用的连接时，池将等待更长的时间（建议的最小可接受超时为 250 毫秒）所以我不能再处理吞吐量了。另一方面，我的逻辑可以在没有数据库的情况下工作一段时间。

我应该如何管理这个？

编辑：

This link 几乎是我想要实现的，减去我希望 HikariCP 自动执行此操作的事实，我不应该激活挂起状态。

【问题讨论】：

我现在也遇到了同样的问题，你有解决这个问题的办法吗？
很遗憾，我记不太清了，但我认为就 Hikari 而言，我使用了 250 毫秒的超时，这根本不是很好。在与我提出这个问题的项目不同的项目中，我使用了 Hystrix，它允许您指定方法的超时以及当方法被认为不可用时的回退（例如，在某些超时之后）。这也应该解决 Hikari 的限制。
我启用了 JMX，并且正在查看池中的总连接数。如果数据源池中的总连接数下降到 0，则意味着到达数据库时出现问题，并且我在调用 getConnection() 之前抛出异常（在 connectionTimeout 期间阻塞）。现在在 totalConnections 降至 0 之前需要一些时间（取决于池中的连接数），因为它必须调用 getConnection() 并阻塞，然后使连接无效并从池中逐出。但是在池为空后，我可以处理缓存中的记录并跳过数据库读取。

标签： java hikaricp

【解决方案1】：

也许您应该在应用程序代码中的某处引入一个计数器，如果并发请求数超过该值，请不要使用数据库。如果不知道你在处理什么，就很难说清楚，例如读与写。

根据brettwooldridge comment regarding connectionTimeout property，由于线程调度，即使有可用连接，较低的超时也不可靠：

我们当然可以考虑降低楼层，但 125 毫秒是绝对最小值。

Windows 和 Linux 的默认调度程序时间均为 20 毫秒。如果在 4 核 CPU 上运行 16 个线程，则单个线程可能必须等待长达 80 毫秒才能被允许运行。如果池由于（例如）在 maxLifetime 时退出连接而出现空缺，则在不向客户端返回虚假故障的情况下，这会留下宝贵的时间来建立连接以填充插槽。

如果不仔细考虑以确保 CPU 和调度程序不会过饱和，以 125 毫秒超时运行，即使池具有可用连接，您的应用程序层也会面临虚假故障的风险。例如，在 4 核 CPU 上运行 32 个线程可能会在负载下导致线程饥饿长达 120 毫秒——非常接近边缘。

【讨论】：

谢谢，Karol，但我的问题略有不同。并发请求的数量无关紧要，无论是读操作还是写操作。我说的是数据库离线的用例，我不希望客户端在需要获取新连接时等待超时到期。