-1

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

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

总而言之，使用的最小数据库连接数是 3000，这可能会变得可笑。

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

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

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

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

我的问题是是否有一个数据库池实现已经这样做了 - 允许我拥有一组连接并自动将我放置在正确的模式中，或者更好的是 - 跟踪池连接是否可用于您的目标模式决定继续并切换模式（节省数据库往返）。

如果您以不同的方式解决它，我还想听听其他有类似问题（现实世界经验）的人的意见。

4

1 回答 1

2

我自己经过艰苦的学习，稳定 Web 应用程序和数据库之间的数据库连接数的最佳方法是在 Web 应用程序前面放置一个反向代理。

这就是它起作用的原因：

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

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

在我进行此架构更改之前，有许多流量高峰导致死亡螺旋：数据库句柄使用率会飙升到耗尽，事情会从那里走下坡路。

更改后，所需的数据库句柄数既少得多，也稳定得多。

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

于 2013-09-09T19:37:08.343 回答