Google Cloud已使AlloyDB for PostgreSQL的“管理式连接池”功能正式投入使用。这一功能现已全面开放，它将类似PgBouncer的功能直接集成到了数据库服务中。根据Google的说法，该功能能使客户端连接数量增加3倍，事务处理吞吐量提高多达5倍——这有效解决了那些需要处理高并发请求的开发者所面临的扩展难题。
连接池技术本身并不是什么新鲜事物。多年来，开发人员们一直使用PgBouncer或pgpool这类工具作为独立的基础设施，用来重复利用数据库连接，从而避免为每个请求都创建新的连接。现在，AlloyDB能够自动完成这一工作。开发人员可以通过控制台选项或API调用来启用该功能，使用这些工具建立的连接会通过端口6432进行通信，而常规的数据库连接则通过端口5432进行通信。
这个“管理式连接池”会预先建立一些连接，并将这些连接分配给传入的请求，在请求处理完成后再将它们放回连接池中，而不是直接关闭它们。Google称，这一机制能够有效消除开发人员在维护连接池时所面临的“运营负担”——因为该连接池会自动接受更新并进行扩展，成为开发者使用AlloyDB实例时不可或缺的一部分。此外，连接池与数据库之间的通信是在Google Cloud的内部网络中进行的，因此相比外部连接的解决方案，这种设置可以显著降低延迟。
对于在Cloud Run或Cloud Functions上运行的无服务器应用来说，这一功能的好处更加明显。这些平台在接收到请求时会创建新的实例，而这些新实例往往会消耗大量的数据库连接资源。而“管理式连接池”能够缓冲这些连接需求，让应用程序通过现有的连接来处理请求，从而避免数据库同时面临数百个新的连接请求。
UKG公司的资深首席架构师Jeff Bogenschneider在早期测试阶段就描述了这一功能带来的影响：他提到：
AlloyDB的架构使我们能够在一个集群中部署比其他任何Postgres管理型服务都更多的数据库。我们之前非常担心连接数量的限制问题，而“管理式连接池”功能帮助我们确保了全球客户的最佳使用体验，让我们能够在不需要担心高峰期连接资源不足的情况下持续发展业务。
那些开发微服务的开发者应该考虑将应用程序端的连接池技术与AlloyDB的“管理式连接池”功能结合起来使用。Adarsha Kuthuru和Kumar Ramamurthy在Medium上详细介绍了这种“双重连接池”方案：像HikariCP这样的应用程序连接池会为每个实例保留5到10个连接，这些连接会被转发到后端的数据库中。这样就可以避免出现50个微服务实例各自拥有20个连接时，导致数据库同时面临1000个连接请求的情况。作者建议，每个vCPU应该使用15到20个连接池连接，并且需要协调不同层级的超时设置，以避免出现连接重置错误。
该功能提供了两种连接池管理模式。默认的“事务模式”通过为每笔交易分配专用连接来提升系统的可扩展性；而“会话模式”则能确保与PostgreSQL的所有功能完全兼容。开发人员可以通过AlloyDB API中标准的PgBouncer参数来调整连接池的大小、超时设置以及空闲连接的阈值。
不过也存在一些需要注意的地方：该管理型连接池机制无法与AlloyDB的认证代理或语言连接器一起使用，因此开发者需要直接建立连接。这会限制那些依赖认证代理进行凭证轮换或简化TLS配置的部署方案。此外，在2024年11月之前的实例上启用连接池功能时，由于VPC配置的更新，系统会出现短暂的网络中断现象（持续时间通常不超过15秒）。
对于那些已经在单独使用PgBouncer的开发人员来说，切换到这种管理型连接池机制主要有助于简化基础设施管理，减少需要维护的组件数量。而对于新部署的项目，尤其是无服务器架构或高并发场景的应用，启用这一功能几乎不需要花费太多精力，而且能够有效预防潜在的可扩展性问题。
谷歌提供了关于如何配置管理型连接池的文档，同时也给出了在现有实例上启用该功能的最佳实践建议。另外，Medium网站上也有相关文章介绍了双连接池模式的部署技巧，为开发者提供了更多参考信息。