jdbc - Hystrix 应该替换现有的 JDBC/HTTP 连接池，还是委托给它们？

Question

许多应用程序将连接池用于 HTTP 和 JDBC 调用以实现弹性。但是使用和配置这两种类型的池是非常不同的。这复制了实现两者共有的弹性模式的复杂性——例如超时、重试、缓存/警报回退、断路和监控。

在我看来， Hystrix为 HTTP 和 JDBC 调用提供了配置和实现这些相同弹性模式的通用方法。

我的问题是：

1. Hystrix 理论上可以完全替代现有的 HTTP 和 JDBC 连接池吗？
2. 如果是这样，这样做的利弊是什么？

完全替换它们可以减少围绕这些连接池的复杂性 - 以及它们伴随的超时和验证查询属性等。但是我对 Hystrix 如何“保持活动” JDBC / HTTP 连接 - 从而避免昂贵的连接设置成本 - 没有委派给专门用于这些任务的现有图书馆。

对于上下文，我有一个 DropWizard 应用程序，它使用 Tomcat DBCP 作为其 JDBC 连接池，使用 Apache HttpClient 作为其 HTTP 连接池。

Answer 1

不，Hystrix 不能替换你的连接池。

Hystrix 的主要特点是：

1. 通过使用有限的线程池或信号量来限制对服务的调用次数。
2. 对服务的调用超时的可能性，以避免应用程序线程被锁定等待慢速/挂起的服务。
3. 添加隔板，以便一项缓慢的服务对应用程序的其余部分的影响最小。
4. 断路缓慢/挂起的服务。

不支持池连接。

我想你可以争辩说第一点与连接池有些相关，因为 Hystrix 和连接池都可以限制对其他系统的负载。但是，拥有连接池的主要原因是池化连接的性能增益。这种负载限制行为基本上是连接池的一个好处。

但是，正如您在问题中所建议的那样，Hystrix 可以通过在连接池前面添加快速故障超时行为和隔板来补充连接池。