谷歌云正式发布AlloyDB for PostgreSQL 通用托管连接池，将类似 PgBouncer 的功能直接集成到数据库服务中。按照谷歌的说法，与直接连接相比，这一特性能够提供 3 倍多的客户端连接和高达 5 倍的事务吞吐量，帮助开发者解决了运行高并发工作负载时面临的扩展挑战。
连接池并不是什么新鲜事。多年来，为了重用数据库连接而不是为每个请求创建新的连接，开发者们将PgBouncer或pgpool作为单独的基础设施进行了部署。现在，AlloyDB 可以自动完成这些工作了。开发者可以通过控制台复选框或 API 调用来启用它，连接池使用 6432 端口，而常规连接使用 5432 端口。
托管连接池会缓存预先建好的连接，将它们分配给传入请求，并在使用完成后将它们返回给连接池，而不是关闭它们。谷歌表示，这可以消除“运维负担”，作为 AlloyDB 实例的一部分，连接池会自动升级和扩展。连接池和数据库之间的通信在谷歌云的网络内运行，可能比外部连接池设置的延迟小。
对于 Cloud Run 或 Cloud Functions 上的无服务器部署，其优势更为显著。这些平台会启动多个实例，每个实例都会打开数据库连接，在流量高峰时往往会超出 PostgreSQL 的连接限制。对于这种情况，连接池是一个很好的缓冲，它利用现有的连接处理请求，而非强制数据库同时处理数百个新的连接尝试。
UKG 高级首席架构师 Jeff Bogenschneider 在早期测试期间描述了其影响：
AlloyDB 的架构使我们能够在单个集群中部署的数据库数量远超其他 Postgres 托管服务。此前我们曾担心连接限制问题，而托管连接池可以帮助我们确保全球的客户都能获得最佳的性能，让我们得以自由地扩展业务，而不用担心在高峰使用时段遇到连接限制问题。
运行微服务的开发者应该考虑将应用端连接池与 AlloyDB 的托管连接池配对。在Medium上，Adarsha Kuthuru 和 Kumar Ramamurthy 详细描述了这种“双池”模式：像 HikariCP 这样的应用连接池为每个实例维持 5-10 个到 AlloyDB 连接池的连接，后者通过多路复用将这些连接连接到数量更少的后端数据库连接。这个方案可以避免为 50 个微服务实例各建立 20 个连接时，1000 个并发连接冲击数据库的场景。作者建议为每个 vCPU 配置 15-20 个连接器连接，并协调各层的超时设置，避免连接重置错误。
该功能提供两种连接池模式。事务模式（默认）通过为每个事务分配独立的连接来最大化可扩展性；会话模式完全兼容 PostgreSQL 的功能。开发者可以通过 AlloyDB API 中的标准 PgBouncer 参数调整连接池规模、超时设置及空闲阈值。
该功能存在一些限制。托管连接池不适用于 AlloyDB Auth Proxy 或语言连接器——开发者需要直接连接。这妨碍了依赖身份验证代理进行凭据轮换或简化 TLS 配置的部署模式。在 2024 年 11 月前部署的实例上启用连接池功能时，由于要更新 VPC 设置，会引发短暂的网络中断（持续时间少于 15 秒）。
对于已经单独运行 PgBouncer 的开发者而言，迁移至托管连接池主要在于整合基础设施——减少一个需要打补丁的组件。对于新增部署，尤其是无服务器或高并发工作负载，启用该功能所需的投入极少，却能防患于未然，在扩展问题爆发前将其及时化解。
谷歌提供了配置托管连接池的文档和在现有实例上启用该特性的最佳实践。对于双池模式，发表在 Medium 上的博文提供了一份部署指南。
原文链接：
https://www.infoq.com/news/2026/01/alloydb-managed-connection-pool/
