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

本文提供为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 和数据库部署

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

PgBouncer 和应用程序并置部署

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

在应用程序 VM 中部署的 PgBouncer

如果应用程序在 Azure VM 上运行，则可以在同一 VM 上设置 PgBouncer。若要使用Azure Database for PostgreSQL灵活服务器安装和配置 PgBouncer 连接池代理，请参阅安装和设置 PgBouncer 连接池代理的步骤。

VM 上应用程序归置的图。

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

优点：

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

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

Limitations:

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

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

部署为 AKS 挎斗的 PgBouncer

如果应用程序在Azure Kubernetes 服务 (AKS)、Azure容器实例（ACI）或Azure 容器应用（ACA）上运行，则可以使用 PgBouncer 作为 sidecar 容器。边车模式的灵感来源于安装在摩托车旁的边车这一概念。辅助容器（称为边车容器）附加到主应用程序。此模式通过扩展父应用程序的功能和提供补充支持来丰富父应用程序。

在 AKS sidecar 中部署 PgBouncer 紧密耦合应用程序和 sidecar 生命周期，并共享主机名和网络等资源，以高效利用资源。 PgBouncer sidecar 与同一 pod 中的应用程序容器一起运行，Azure Kubernetes 服务 (AKS)具有 1：1 映射，充当Azure Database for PostgreSQL灵活服务器的连接池代理。

Microsoft在Microsoft容器注册表中发布 PgBouncer sidecar 代理映像。

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

应用程序在挎斗共驻的图示。

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

优点：

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

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

Limitations:

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

在考虑这种边车模式时，请仔细权衡部署复杂性与可扩展性需求之间的利弊，从而确定最适合您的具体应用场景的方案。

与应用程序无关 - 集中式 PgBouncer 部署

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

部署在 Ubuntu VM 上且位于 Azure 负载均衡器后端的 PgBouncer

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

若要使用Azure Database for PostgreSQL灵活服务器安装和设置 PgBouncer 连接池代理，请参阅安装和设置 PgBouncer 连接池代理的步骤。

VM 上使用负载均衡器的应用程序归置的图。

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

优点：

删除单一故障点：应用程序连接不受单个 PgBouncer VM 故障的影响，因为多个 PgBouncer 实例落后于Azure 负载均衡器。
与托管服务的无缝集成：如果应用程序托管在托管服务平台（如 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，此配置非常有用。例如，将 SSLMODE 参数更改为Azure Database for PostgreSQL灵活服务器上的“必需”可能会导致依赖于 SSLMODE=FALSE 的某些应用程序失败。在单独的 VM 上部署 PgBouncer 可以维护默认服务器配置，同时仍使用 PgBouncer 的优势。

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

Limitations:

管理开销： 在 VM 中安装 PgBouncer 时，可能需要管理开销来管理多个配置文件。此设置使得难以应对版本升级、新版本和产品更新。
功能一致性：如果你正从传统 PostgreSQL 迁移到 Azure Database for PostgreSQL 灵活服务器，并使用 PgBouncer，则某些功能可能会有所差异。例如，Azure Database for PostgreSQL 中缺少 md5 支持。

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

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

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

使用 Microsoft 容器注册表中发布的 PgBouncer sidecar 代理映像来创建和部署服务。

PgBouncer 作为 AKS 服务中的一个图示。

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

优点：

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

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

Limitations:

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

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

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 Database for PostgreSQL灵活服务器中使用内置的 PgBouncer，不需要单独的安装或复杂的设置。你可以直接从参数轻松配置它，确保无麻烦的体验。
托管服务便利性：作为托管服务，你可以享受其他Azure托管服务的优势。此权益包括自动更新，无需手动维护，并确保 PgBouncer 随时了解最新功能和安全修补程序。
公共连接和专用连接支持：Azure Database for PostgreSQL灵活服务器中的内置 PgBouncer 为公共连接和专用连接提供支持。此支持允许你通过专用网络建立安全连接，或根据具体的要求在外部连接。
高可用性 (HA)：在发生故障转移（备用服务器提升为主服务器）时，PgBouncer 会在新提升的备用服务器上无缝重启，而无需更改应用程序连接字符串。此功能可确保持续可用性，并最大程度地减少应用程序中断。
经济高效： 这是经济高效的，因为不需要为额外的计算（如 VM 或容器）付费，尽管它确实会对 CPU 造成一些影响，因为它是在同一台计算机上运行的另一个进程。

通过在 Azure Database for PostgreSQL 灵活服务器中使用内置的 PgBouncer，您可以享受简化配置的便利、托管式服务的可靠性、对各种连接池模式的支持，以及在故障转移场景中的无缝高可用性。

Limitations:

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

本文讨论实现 PgBouncer 的不同方法。下表总结了要选择的部署方法：