如何在大规模Java App中限制数据库连接

Question

我有一个包含100多台服务器的Java应用程序。目前，每个服务器都打开了与关系数据库中7个数据库模式的连接（日志记录，这个，那个，另一个）。所有模式都连接到同一个数据库集群，但它实际上只有一个数据库实例。

服务器管理的连接池在每个实例的每个数据库模式上打开一个连接（1 - 5），然后在冗余池上加倍。因此，每台服务器至少可以打开30个数据库连接，每个服务器最多可以增加到几百个服务器，而且服务器数量也会超过100个。

总而言之，所使用的最小数据库连接数为3000，这可能会变得很有可能。

显然这是完全错误的。数据库集群只能有效地处理X个并发请求和任意数量的请求。 X引入了不必要的争用并减慢了整个数量。 （X未知，但它比3000最小并发连接小。）

我想降低实施以下策略所使用的总连接数：

1. 仅连接到一个模式（Application-X），每个池最多有6个连接。
2. 在池上方写一个层，切换到我想要的架构。 getConnection（forSchema）函数将获取目标模式的参数（例如，日志记录），将获得可能最后指向任​​何模式的连接，并发出模式切换SQL语句（将search_path设置为“target_schema”）。 / LI>

   请不要评论这种方法是对还是错。因为需要考虑“它取决于”，这样的评论不会增加价值。

   我的问题是，是否存在已经执行此操作的数据库池实现 - 允许我拥有一组连接并自动将我置于正确的架构，或者更好 - 跟踪是否可以为您提供池化连接在决定继续并切换模式之前的目标模式（保存数据库往返）。

   如果您以不同的方式解决问题，我也希望听到其他有类似问题（实际经验）的人。

Answer 1

自己学到了很多困难，稳定Web应用程序和数据库之间数据库连接数的最佳方法是在Web应用程序前面放置一个反向代理。

这就是它起作用的原因：

Web请求的缓慢部分可以将数据返回给客户端。如果存在大量数据或用户连接速度较慢，则连接可以保持对Web服务器开放，其中数据会缓慢地传输到客户端。同时，应用程序服务器继续保持对后端服务器开放的数据库连接。虽然数据库连接可能只需要一小部分事务，但它会被绑定，直到客户端与应用程序服务器断开连接。

现在，考虑在应用服务器前面添加反向代理时会发生什么。当应用服务器准备好响应时，它可以快速回复到它前面的反向代理，并释放其后面的数据库连接。然后，反向代理可以处理缓慢运行对使用的响应，而不会保持相关的数据库连接。

在我进行这种架构更改之前，有一些流量峰值导致了死亡螺旋：数据库句柄的使用会飙升到疲惫状态，事情会从那里走下坡路。

更改后，所需的数据库句柄数量要少得多，而且要稳定得多。

如果反向代理不是您的体系结构的一部分，我建议将其作为控制所需数据库连接数的第一步。