你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

使用 PgBouncer 的 Azure Database for PostgreSQL 灵活服务器的连接池策略

适用于： Azure Database for PostgreSQL 灵活服务器

为 Azure Database for PostgreSQL 灵活服务器选择连接池机制的战略指导。

介绍

使用 Azure Database for PostgreSQL 灵活服务器时，建立与数据库的连接涉及在客户端应用程序和服务器之间创建信道。 此通道负责管理数据、执行查询和启动事务。 建立连接后，客户端应用程序可以将命令发送到服务器并接收响应。 但是，为每个操作创建新连接可能会导致任务关键型应用程序出现性能问题。 每次创建新连接时，Azure Database for PostgreSQL 灵活服务器都会使用 postmaster 进程生成一个新进程，这会消耗更多资源。

为了缓解此问题，连接池用于创建可在 Azure Database for PostgreSQL 灵活服务器中重复使用的连接缓存。 当应用程序或客户端请求连接时，它是从连接池创建的。 会话或事务完成后，连接将返回到池以供重复使用。 通过重用连接，可减少资源使用量并提高性能。

尽管连接池有不同的工具，但在本部分中，我们将讨论使用 PgBouncer 使用连接池的不同策略。

什么是 PgBouncer？

PgBouncer 是专为 PostgreSQL 设计的高效连接池程序，在管理与一个或多个数据库的多个客户端连接方面具有减少处理时间和优化资源使用的优势。 PgBouncer 为连接轮换合并了三种不同的池模式：

• 会话池：此方法在客户端连接的整个持续时间内将服务器连接分配给客户端应用程序。 客户端应用程序断开连接后，PgBouncer 会立即将服务器连接返回到池。 会话池机制是开源 PgBouncer 中的默认模式。 请参阅 PgBouncer 配置
• 事务池：使用事务池时，服务器连接在事务期间专用于客户端应用程序。 事务成功完成后，PgBouncer 会智能释放服务器连接，使其在池中再次可用。 事务池是 Azure Database for PostgreSQL 灵活服务器内置 PgBouncer 中的默认模式，它不支持准备好的事务。
• 语句池：在语句池中，每个语句的服务器连接都分配给客户端应用程序。 语句完成后，服务器连接会立即返回到连接池。 请务必注意，此模式不支持多语句事务。

PgBouncer 的有效利用可分为三种不同的使用模式。

• PgBouncer 和应用程序归置部署
• 独立于应用程序的集中式 PgBouncer 部署
• 内置 PgBouncer 和数据库部署

每种模式都有自己的优缺点。

1. PgBouncer 和应用程序并置部署

使用此方法时，PgBouncer 部署在托管应用程序的同一服务器上。 应用程序与 PgBouncer 可以部署在传统虚拟机上，也可以部署在基于微服务的体系结构中，如下所示：

I. 应用程序 VM 中部署的 PgBouncer

如果应用程序在 Azure VM 上运行，则可以在同一 VM 上设置 PgBouncer。 若要安装 PgBouncer 并将其配置为 Azure Database for PostgreSQL 灵活服务器的连接池代理，请按照以下链接中提供的说明进行操作。

在应用程序服务器中部署 PgBouncer 可以提供多种优势，尤其是在使用 Azure Database for PostgreSQL 灵活服务器数据库时。 此部署方法的一些主要优势和限制包括：

优点：

• 降低延迟：通过在同一应用程序 VM 上部署 PgBouncer，主应用程序和连接池程序之间的通信由于邻近性而高效。 在应用程序 VM 中部署 PgBouncer 可最大程度地减少延迟并确保流畅、快速的交互。
• 提高安全性：PgBouncer 可以充当应用程序和数据库之间的安全中介，从而提供额外的安全层。 它可以强制实施身份验证和加密，确保只有经过授权的客户端才能访问数据库。

总体而言，在应用程序服务器中部署 PgBouncer 提供了一种更高效、更安全且可缩放的方法来管理与 Azure Database for PostgreSQL 灵活服务器数据库的连接，从而提高了应用程序的性能和可靠性。

限制：

• 单一故障点：如果将 PgBouncer 部署为应用程序服务器上的单个实例，则它将成为潜在的单一故障点。 如果 PgBouncer 实例出现故障，可能会中断整个数据库连接池，从而导致应用程序停机。 若要缓解单一故障点，可以在负载均衡器后面设置多个 PgBouncer 实例，以实现高可用性。
• 受限的可伸缩性：PgBouncer 可伸缩性取决于部署它的服务器的容量。 如果应用程序服务器达到其连接限制，PgBouncer 可能会成为瓶颈，从而限制缩放应用程序的能力。 可能需要跨多个 PgBouncer 实例分配连接负载，或者考虑在应用程序级别考虑其他解决方案，例如连接池。
• 配置复杂性：配置和微调 PgBouncer 可能比较复杂，尤其是在考虑连接限制、池大小调整和负载均衡等因素时。 管理员需要仔细优化 PgBouncer 配置，以满足应用程序的要求，并确保最佳性能和稳定性。

请务必权衡这些限制与优势，并评估 PgBouncer 是否是特定应用程序和数据库设置的正确选择。

II. 部署为 AKS 挎斗的 PgBouncer

如果应用程序已容器化并在 、Azure Kubernetes 服务 (AKS)、Azure 容器实例 (ACI)、Azure 容器应用 (ACA) 或 Azure Red Hat OpenShift (ARO) 上运行，可以使用 PgBouncer 作为挎斗容器。 挎斗模式的灵感来自附加到摩托车的挎斗概念，其中辅助容器（称为挎斗容器）附加到父应用程序。 此模式通过扩展父应用程序的功能和提供补充支持来丰富父应用程序。

挎斗模式通常用于将共同计划为原子容器组的容器。 在 AKS 挎斗中部署 PgBouncer 会将应用程序和挎斗生命周期紧密耦合，并共享主机名和网络等资源，以便有效地利用资源。 PgBouncer 挎斗与 Azure Kubernetes 服务 (AKS) 中同一 Pod 中的应用程序容器一起运行，具有 1:1 映射，充当 Azure Database for PostgreSQL 灵活服务器的连接池代理。

此挎斗模式通常用于将共同计划为原子容器组的容器。 挎斗模式强绑定应用程序和挎斗生命周期，并具有共享资源，如主机名和网络。 通过使用此设置，PgBouncer 可以优化连接管理并促进应用程序与 Azure Database for PostgreSQL 灵活服务器实例之间的高效通信。

Microsoft 已在 Microsoft 容器注册表中发布了 PgBouncer 挎斗代理映像。

请参阅本文了解详细信息。

此部署方法的一些主要优势和限制包括：

优点：

• 降低延迟：通过将 PgBouncer 部署为 AKS 挎斗，主应用程序和连接池程序之间的通信由于邻近性而无缝且高效。 将 PgBouncer 部署 AKS 挎斗可以最大程度地减少延迟，并确保顺畅、快速的交互。
• 简化的管理和部署：PgBouncer 与应用程序容器的紧密耦合简化了管理和部署过程。 这两个组件都紧密集成，可以简化管理和无缝协调。
• 高可用性和连接复原能力：如果应用程序容器失败或重启，PgBouncer 挎斗容器将紧随其后，确保高可用性。 此设置可保证连接复原能力，即使在故障转移期间也能保持可预测的性能，从而构建一个可靠强大的系统。

通过将 PgBouncer 视为 AKS 挎斗，可以利用这些优势来增强应用程序的性能、简化管理并确保连接池程序的持续可用性。

限制：

• 连接性能问题：使用数千个 Pod（每个运行挎斗 PgBouncer）的大规模应用程序可能会遇到与数据库连接耗尽相关的潜在挑战。 这种情况可能会导致性能下降和服务中断。 为每个 Pod 部署挎斗 PgBouncer 会增加与数据库服务器的并发连接数，这可能会超过其容量。 因此，数据库可能难以处理大量传入连接，可能会导致性能问题，例如响应时间增加，甚至服务中断。
• 复杂部署：使用挎斗模式给部署过程带来了一定程度的复杂性，因为它涉及到在同一 Pod 中运行两个容器。 这可能会使故障排除和调试活动复杂化，需要付出额外的精力来识别和解决问题。
• 缩放挑战：请务必注意，对于需要高可伸缩性的应用程序，挎斗模式可能不是理想的选择。 包含挎斗容器可能会施加更多资源要求，从而可能限制可有效创建和管理的 Pod 数。

在考虑此挎斗模式时，请务必仔细评估部署复杂性和可伸缩性要求之间的权衡，以确定最适合特定应用程序方案的方法。

2.独立于应用程序 - 集中式 PgBouncer 部署

使用此方法时，PgBouncer 将部署为独立于应用程序的集中式服务。 PgBouncer 服务可以部署在传统虚拟机上，也可以部署在基于微服务的体系结构中，如下所示：

I. PgBouncer 部署在 Azure 负载均衡器后面的 ubuntu VM 中

PgBouncer 连接代理设置在 Azure 负载均衡器后面的应用程序和数据库层之间，如下图所示。 在此模式中，多个 PgBouncer 实例作为服务部署在负载均衡器后面，以减少单一故障点。 此模式也适用于应用程序在 Azure 应用服务或 Azure Functions 等托管服务上运行并连接到 PgBouncer 服务以便轻松与现有基础结构集成的场景。

请参阅有关为 Azure Database for PostgreSQL 灵活服务器安装和设置 PgBouncer 连接池代理的链接。

此部署方法的一些主要优势和限制包括：

优点：

• 删除单一故障点：应用程序连接可能不受单个 PgBouncer VM 故障的影响，因为 Azure 负载均衡器后面有多个 PgBouncer 实例。
• 与托管服务的无缝集成：如果应用程序托管在托管服务平台（如 Azure 应用服务或 Azure Functions）上，在 VM 上部署 PgBouncer 可以方便地与现有基础结构集成。
• Azure VM 上的简化设置：如果已在 Azure VM 上运行应用程序，则在同一 VM 上设置 PgBouncer 非常简单。 在 VM 中部署 PgBouncer 可确保 PgBouncer 部署在靠近应用程序的位置，从而最大程度地降低网络延迟并最大程度地提高性能。
• 非侵入性配置：通过在 VM 上部署 PgBouncer，可以避免在 Azure Database for PostgreSQL 灵活服务器上修改服务器参数。 如果需要在 Azure Database for PostgreSQL 灵活服务器实例上配置 PgBouncer 时，此方法非常有用。 例如，在 Azure Database for PostgreSQL 灵活服务器上将 SSLMODE 参数更改为“必需”可能会导致依赖于 SSLMODE=FALSE 的某些应用程序失败。 在单独的 VM 上部署 PgBouncer 可以维护默认服务器配置，同时仍使用 PgBouncer 的优势。

通过考虑这些优势，在 VM 上部署 PgBouncer 提供了一种方便高效的解决方案，用于增强在 Azure 基础结构上运行的应用程序的性能和兼容性。

限制：

• 管理开销：由于 VM 中安装了 PgBouncer，因此管理多个配置文件可能会有管理开销。 这使得难以应对版本升级、新版本发布和产品更新。
• 功能奇偶一致性：如果要从传统 PostgreSQL 迁移到 Azure Database for PostgreSQL 灵活服务器并使用 PgBouncer，则可能存在一些功能差距。 例如，Azure Database for PostgreSQL 灵活服务器中缺少 md5 支持。

II. 作为 AKS 中的服务部署的集中式 PgBouncer

如果在由数百个 Pod 组成的 Azure Kubernetes 服务 (AKS) 上使用高度可缩放的大型容器化部署，或者在多个应用程序需要连接到共享数据库的情况下，可以将 PgBouncer 用作独立服务而不是挎斗容器。

通过将 PgBouncer 用作单独的服务，可以更广泛地有效地管理和处理应用程序的连接池。 此方法允许集中连接池功能，使多个应用程序能够连接到同一数据库资源，同时保持最佳性能和资源利用率。

在 Microsoft 容器注册表中发布的 PgBouncer 挎斗代理映像可用于创建和部署服务。

此部署方法的一些主要优势和限制包括：

优点：

• 增强的可靠性：将 PgBouncer 部署为独立服务允许以高度可用的方式进行配置。 这提高了连接池基础结构的整体可靠性，确保即使在遇到故障或中断时也能持续可用。
• 最佳资源利用率：如果应用程序或数据库服务器的资源有限，则选择专用于运行 PgBouncer 服务的单独计算机可能更有利。 通过在资源充足的计算机上部署 PgBouncer，可以确保最佳性能并防止资源争用问题。
• 集中式连接管理：当需要集中管理数据库连接时，独立的 PgBouncer 服务可提供更简化的方法。 通过将连接管理任务合并到集中式服务中，可以跨多个应用程序有效地监视和控制数据库连接，从而简化管理并确保一致性。

通过将 PgBouncer 视为 AKS 中的独立服务，可以利用这些优势来提高可靠性、资源效率，并集中管理数据库连接。

限制：

• 增加 N/W 延迟：将 PgBouncer 部署为独立服务时，请务必考虑可能会引入更多延迟。 这是因为需要在应用程序和 PgBouncer 服务之间通过网络传递连接。 评估应用程序的延迟要求并考虑集中连接管理与潜在延迟问题之间的权衡至关重要。

虽然作为独立服务运行的 PgBouncer 具有集中管理和资源优化等优势，但请务必评估潜在延迟对应用程序性能的影响，以确保它符合你的特定要求。

3.Azure Database for PostgreSQL 灵活服务器中的内置 PgBouncer

Azure Database for PostgreSQL 灵活服务器将 PgBouncer 作为内置连接池解决方案予以提供。 此项作为可选服务提供，可在每个数据库服务器的基础上启用。 PgBouncer 在与 Azure Database for PostgreSQL 灵活服务器实例相同的虚拟机中运行。 随着连接数量超过数百或数千，Azure Database for PostgreSQL 灵活服务器可能会遇到资源限制。 在这种情况下，内置的 PgBouncer 可以通过改进对数据库服务器上的空闲和短期连接的管理来提供显著优势。

请参阅有关在 Azure Database for PostgreSQL 灵活服务器中启用和设置 PgBouncer 连接池的内容的链接。

此部署方法的一些主要优势和限制包括：

优点：

• 无缝配置：使用 Azure Database for PostgreSQL 灵活服务器中的内置 PgBouncer，无需单独安装或复杂的设置。 该功能可以直接通过服务器参数轻松配置，确保使用简单。
• 托管服务便利：作为一项托管服务，可为用户提供其他 Azure 托管服务的优势。 这包括自动更新，这样便无需手动维护并可确保 PgBouncer 及时引入最新的功能和安全修补程序。
• 公共和专用连接支持：Azure Database for PostgreSQL 灵活服务器中的内置 PgBouncer 提供对公共和专用连接的支持。 这允许用户根据其特定要求通过专用网络建立安全连接或连接到外部。
• 高可用性 (HA)：如果发生故障转移，备用服务器将被提升为主要角色,PgBouncer 将在新提升的备用服务器上无缝重新启动，而不需要对应用程序连接字符串进行任何更改。 这可确保持续可用性，将对应用程序的中断降到最低。
• 经济高效：它具有成本效益，因为用户不需要为 VM 或容器等额外计算付费，尽管它确实会产生一些 CPU 影响（因为它是在同一台计算机上运行的另一个进程）。

借助 Azure Database for PostgreSQL 灵活服务器中内置的 PgBouncer，用户可以体验简化配置的便利、托管服务的可靠性、对各种池模式的支持以及故障转移场景下的无缝高可用性。

限制：

• 不支持可突发：PgBouncer 目前不支持可突发服务器计算层。 如果将计算层从常规用途或内存优化更改为可突发层，则你将无法使用 PgBouncer。
• 重启后重新建立连接：每当在执行缩放操作、HA 故障转移或重新启动期间重启服务器时，PgBouncer 也会随服务器虚拟机一同重启。 因此，必须重新建立现有连接。

我们讨论了实现 PgBouncer 的不同方法，下表总结了要选择的部署方法：

选择条件	应用 VM 上的 PgBouncer	*使用 ALB 的 VM 上的 PgBouncer	AKS 挎斗上的 PgBouncer	PgBouncer 即服务	Azure Database for PostgreSQL 灵活服务器内置 PgBouncer
简化管理
高可用性
容器化应用
降低网络开销和延迟
监视和调试的精细控制

图例

难度级别	符号
简单
中
困难

*ALB：Azure 负载均衡器。