TCP 负载均衡器是否可以替代 Postgres 9.X 读取从属负载均衡器（如 pgPool II 或 pgBouncer）？

Question

为了扩展 PostgreSQL 流复制从属设备上的读取流量，我希望能够对请求进行负载平衡。Postgres 文档建议使用 pgPool 和 pgBouncer 之类的工具，但我想知道在 postgres 读取从站前面使用 TCP 负载均衡器（如 HAProxy 或 AWS Elastic Load Balancer）是否有问题（原则上）。

负载均衡器充当需要由客户端发出的读取请求的单个读取端点。一个显着的优势是当读取从属服务器关闭时读取请求不会受到影响，因为负载均衡器中的其他服务器可以接收负载。

Answer 1

原则上没有问题，虽然我自己还没有使用过。

大多数客户端应用程序维护长会话 - 因此负载平衡实际上始终是“粘性的”。这很容易导致一个节点的负载比其他节点多得多。一种解决方法是有意限制连接持续时间，强制应用偶尔重新连接并可能被分配到不同的节点。这还可以让您在负载较轻时通过将工作折叠到更少的节点上来缩小系统，而不是卡在大量节点上，每个节点大多空闲，只有一两个活动连接。

您的应用程序必须仔细编写以检查所有返回代码/处理异常。他们必须重试由于连接丢失等暂时性错误而失败的事务，这意味着他们必须记住他们所做的一切，直到他们提交每个事务。无论如何，这是一个很好的应用程序设计，如果断开连接和事务中止不是日常操作的正常部分，那么懒惰会更容易逃脱。

理论上，PgPool 可以允许读取副本的“透明”负载平衡，同时仍然允许向主节点写入查询。在实践中，我发现它通常很繁琐而且很难正确，所以我通常想让应用程序知道单独的“只读”和“写/主”连接。

PgBouncer 提供的 TCP 负载平衡的主要优点是（在事务池模式下）它让应用程序保持空闲连接，而不会在后备 PostgreSQL 服务器上强加开销。因此，您可以对 PgBouncer 进行一次昂贵的握手、SSL 协商、身份验证等，并让它仅在它正在执行某些操作时将连接绑定到池中的实际 PostgreSQL 后端。这允许最佳利用 Pg 后端并减少闲置后端的数量，除了消耗资源和等待工作之外什么都不做。不过，这仅在您的应用程序可以处理事务池（或语句池）模式时才有价值；如果由于使用会话变量、侦听/通知、咨询锁或其他原因而只能使用会话池模式，则没有任何好处。

如果您使用 TCP 负载平衡，您应该能够像使用 PgPool 或 PgBouncer 一样进行 SSL 卸载，至少使用足够智能的负载平衡器。但是，您将无法执行依赖于 pg_hba.conf 的客户端证书身份验证等操作。

大多数时候我倾向于扩大规模而不是扩大规模，所以目前这不是我需要探索的东西。不过，我有一些工作正在筹备中，这将使扩展 Pg 变得非常有趣，所以我必须尝试一下。