使用PgBouncer与WildFly/Application Server连接池的优势是什么？

Question

许多应用服务器都集成了连接池，甚至独立应用程序也可以配置使用像HikariCP、Apache DBCP等连接池。那么，在应用程序已经有连接池的情况下，使用PgBouncer的优势是什么呢？我找到的最接近的答案是What are advantages of using transaction pooling with pgbouncer?，它没有提到使用另一个连接池，并且提到优势在于空闲会话的使用。我主要使用配置了最小池大小、最大池大小、空闲超时等的WildFly，因此当它们不在使用时，它会自动删除闲置连接（如果这是主要优势的话）。这让我想到PgBouncer在这种情况下并不适合，我只需继续使用应用服务器连接池即可。顺便说一下，在事务池模式下，PgBouncer无法使用命名预处理语句，这似乎不是一个明智的性能选择。如果有任何优势，它是否与wildfly连接池兼容？

- JorSol

---

pgBouncer通常用于在主服务器和从服务器之间进行负载均衡时。如果您只连接到单个Postgres服务器，则应用程序服务器中的连接池就足够了。 - user330315

Answer 1

如果您的应用程序服务器已经包含连接池，并且只有一个应用程序服务器连接到数据库，建议使用集成的连接池。

在这种情况下，pgBouncer 只是额外增加了一个使架构更加复杂的组件，并且您需要处理应用程序服务器和 pgBouncer 之间所有连接的额外开销。

如果有多个应用程序服务器连接到同一数据库，问题就不那么简单了。如果只有两到三个应用程序服务器，则可能不需要使用 pgBouncer。

连接到数据库服务器的应用程序服务器越多，您将拥有越多的数据库连接，这会给数据库带来风险：如果太多的这些连接同时变得繁忙，您的数据库性能和响应时间将会降低，因为数据库过载了。

在这种情况下，pgBouncer 将有助于限制活动连接的数量，以提高性能。

- Laurenz Albe

---

是的，但这并没有回答我的问题。假设我有2或3个应用服务器连接到数据库（将应用程序集群化比数据库更容易），我仍然看不出使用PgBouncer的优势，因为正如你所说，它只是一个使架构更加复杂的额外组件。 - JorSol

你没有说你有多个应用服务器。我会编辑答案来评论这一点。 - Laurenz Albe

感谢Laurenz的编辑，但我仍然没有完全理解这个优势。我可以限制应用程序服务器连接池中的最大连接数，因此我不明白这会如何使数据库面临风险，除非根据负载动态启动应用程序服务器？而且，最好的功能是“事务池”，需要仔细测试，因为它可能会破坏与会话相关的许多内容，并且会失去命名准备语句。 - JorSol

如果你有20个应用服务器，每个服务器都有50个连接池连接到同一个数据库，那么你可能会在数据库上拥有1000个连接，这些连接都可能同时运行语句。这会导致数据库服务器崩溃。使用pgBouncer，你可以减少连接到数据库的数量，使数据库保持功能，一些应用线程将不得不等待直到连接可用。这种“节流”机制可以提高系统的吞吐量和可用性。 - Laurenz Albe