具有多个模式和用户的连接池 Postgres

Posted 2023-02-23

【中文标题】具有多个模式和用户的连接池 Postgres

【英文标题】：Connection pooling Postgres with multiple schemas and users

【发布时间】：2020-03-21 16:24:57

【问题描述】：

将 Postgres 与每个客户的架构一起使用。为了隔离和安全。每个架构有一个不同的用户来限制访问。寻找一种方法来有效地跨模式汇集连接。

已尝试使用应用程序级连接池 (Hikari)，但我认为它无法有效地跨模式进行池化。不希望通过增加每个模式/用户的连接数来达到 Postgress 连接数的限制。而且一般来说，如果连接作为模式的一个因素增长，它似乎并不是最有效的连接池方法。

还尝试了pgbouncer，但不确定如何为此目的有效地配置它。尝试在每个客户的应用程序端使用 Hikari，并使用 pgbouncer 将这些映射到更少的 postgres 连接。在会话模式下，pgbouncer 似乎只是充当代理，连接数随着来自 Hikari 的每个连接而增长。在事务模式下，pgbouncer 和 Hikari 似乎不知何故不同步，我从 Postgres 收到协议错误消息。

这个问题似乎与几年前的this 问题非常相似。不幸的是，我没有看到关于如何有效管理这种类型的连接池的明确答案。

因此，根据客户的说法，可能有相当多的模式，问题是在使用多个模式和用户时如何正确地为 Postgres 进行连接池？

【问题讨论】：

您有多少客户？每个客户有多少个同时连接？我不认为模式是一个问题，但用户肯定可以。您基本上需要为每个客户提供一个单独的池。

假设有数百个客户。但是每个客户怎么会有一个游泳池呢？即使每个池只有几个连接和数百个客户，您最终会得到太多的连接。

是的，这就是拥有数百个用户的问题。每个连接都需要一个池，因为一个连接不能跨用户，但实际上不能为每个连接创建一个池。

【参考方案1】：

每个架构有不同的用户来限制访问。

这真的有效吗？您的应用程序服务器是否不需要知道如何以每个用户的身份进行连接才能完成其工作？如果我可以诱骗应用服务器向我显示来自错误架构的数据，难道我不能在这样做之前像错误的用户一样轻松地诱使它连接吗？

如果是这样，我认为这两个安全“层”并不是真正相互独立的，所以它们并不是真正的两层。

【讨论】：

是的，你说得有道理。你会建议做什么？使用一个用户并使用它查询每个模式，允许池连接？我认为这个想法是不能欺骗查询本身来显示其他模式，因为用户将无权访问这些模式。

我认为防止 SQL 注入的标准方法应该可以防止这种情况。如果您不相信这些方法可以 100% 使用，那么添加用户级别确实会有所收获，但成本很高。你需要一个游泳池吗？连接池通常是试图掩盖其他问题——你能用其他方式识别和解决它吗？