摘要：谷歌云正式发布"AlloyDB for PostgreSQL通用托管连接池，将类似PgBouncer的功能直接集成到数据库服务中。nbsp;连接池并不是什么新鲜事。连接池和数据库之间的通信在谷歌云的网络内运行，可能比外部连接池设置的延迟小。
谷歌云正式发布"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/"
谷歌云正式发布"AlloyDB for PostgreSQL通用托管连接池，将类似PgBouncer的功能直接集成到数据库服务中。按照谷歌的说法，与直接连接相比，这一特性能够提供3倍多的客户端连接和高达5倍的事务吞吐量，帮助开发者解决了运行高并发工作负载时面临的扩展挑战。
连接池并不是什么新鲜事。多年来，为了重用数据库连接而不是为每个请求创建新的连接，开发者们将PgBouncer"或pgpool"作为单独的基础设施进行了部署。现在，AlloyDB可以自动完成这些工作了。开发者可以通过控制台复选框或API调用来启用它，连接池使用6432端口，而常规连接使用5432端口。
托管连接池会缓存预先建好的连接，将它们分配给传入请求，并在使用完成后将它们返回给连接池，而不是关闭它们。谷歌表示，这可以消除“运维负担”，作为AlloyDB实例的一部分，连接池会自动升级和扩展。连接池和数据库之间的通信在谷歌云的网络内运行，可能比外部连接池设置的延迟小。
对于Cloud Run或Cloud Functions上的无服务器部署，其优势更为显著。这些平台会启动多个实例，每个实例都会打开数据库连接，在流量高峰时往往会超出PostgreSQL的连接限制。对于这种情况，连接池是一个很好的缓冲，它利用现有的连接处理请求，而非强制数据库同时处理数百个新的连接尝试。
UKG高级首席架构师Jeff Bogenschneider在早期测试期间描述了其影响：
运行微服务的开发者应该考虑将应用端连接池与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/"