PgDog：打破连接池器“漏油抽象”的下一代 Postgres 代理

PgDog 通过内置 SQL 解析器、多线程 Tokio 运行时和原生 LISTEN/NOTIFY 支持，解决了传统连接池器（如 PgBouncer）中 SET 语句状态泄漏、发布/订阅功能缺失和单进程性能瓶颈的问题。

背景：为什么 Postgres 需要连接池？

PostgreSQL 的每个客户端连接都会消耗服务器资源（内存、文件描述符、进程/线程）。默认情况下，Postgres 的最大连接数通常设置为 100-500，但现代微服务架构中，每个服务实例都可能创建数十个连接，很快就能耗尽数据库连接池。连接池器（connection pooler）作为代理层，让多个客户端复用少量数据库连接，从而突破这一限制。

现有的连接池器包括：

• PgBouncer：最流行的轻量级池器，使用单进程事件循环模型。
• RDS Proxy：AWS 托管的池器，支持自动缩放。
• Pgpool-II：功能更丰富的中间件（含负载均衡、读写分离）。
• Supavisor：Supabase 的云原生池器。

但所有这些工具都引入了一个核心问题：泄漏的抽象（Leaky Abstraction）。

泄漏的抽象：连接池器的“原罪”

传统池器遵循 Unix 哲学——“只做一件事，并做好”。PgBouncer 正是因此成功：它简单、稳定、高效。但它的“一件事”是连接复用，而代价是屏蔽了 Postgres 的会话级状态。

当你部署 PgBouncer 或 RDS Proxy 时，你会很快发现它改变了使用数据库的方式：

• 你必须修改应用代码来绕过某些特性。
• 对于已有大量生产代码的团队，这意味着要修改数千行代码，且通常缺乏测试覆盖。

PgDog 的目标是让连接池器变得透明——像直接连接 Postgres 一样使用它，无需妥协。

核心问题 1：连接状态泄漏（SET 语句）

问题描述

SET 语句用于临时覆盖数据库会话参数。例如：

sql
SET statement_timeout TO '5m';
SELECT * FROM users WHERE banned IS true;

在直接连接中，SET 只影响当前会话。但在连接池中，一个客户端执行 SET 后，连接被归还池中；下一个客户端复用该连接时，会继承上一个客户端的 SET 状态。这导致：

• 最佳情况：慢查询意外获得长超时，引发数据库事故。
• 最坏情况：依赖会话变量的行级安全（RLS）策略失效，数据行静默消失。

传统解决方案：“不要使用 SET”。但 SET 是 Postgres 的核心功能，放弃它意味着：

• 必须用其他方式实现超时控制（如应用层）。
• 如果使用 RLS（常见于多租户应用），则完全无法使用连接池。

PgDog 的解法：内置 SQL 解析器

PgDog 内置了一个轻量级 SQL 解析器，可以：

1. 检测 SET 语句：解析出变量名和值。
2. 按客户端存储状态：在代理层为每个客户端连接维护一个状态副本。
3. 自动同步：当客户端发送查询时，PgDog 检查其状态是否与后端连接匹配。如果不匹配，自动执行一系列 SET 语句来恢复状态。

性能优化：

• 使用查询流水线（query pipelining）：如果多个变量不同，一次性批量发送 SET 语句，只需一次网络往返。
• 解析算法极快，几乎不增加延迟。

效果：开发者可以继续使用 SET 语句，就像直接连接 Postgres 一样。

核心问题 2：LISTEN/NOTIFY 支持

问题描述

LISTEN/NOTIFY 是 Postgres 内置的发布/订阅机制：

• 客户端通过 LISTEN channel 订阅频道。
• 任何客户端通过 NOTIFY channel, 'payload' 发送消息。
• 订阅的客户端会收到通知。

这是一个轻量级的消息队列，常用于：

• 缓存失效通知。
• 实时更新推送。
• 跨进程协调。

但在事务模式（transaction mode） 的池器中，连接在事务结束后被归还，LISTEN 状态丢失。因此，开发者不得不迁移到 SQS、Redis Pub/Sub 等外部系统。

PgDog 的解法：代理作为 pub/sub 中间人

PgDog 在内部实现了完整的 LISTEN/NOTIFY 协议：

1. 进程内通信：使用 Tokio 的 broadcast channel 在同一个 PgDog 进程内的客户端之间传递消息。
2. 跨进程支持：生产环境通常运行多个 PgDog 实例（容器），PgDog 会通过一个专用连接将 LISTEN/NOTIFY 命令转发到 Postgres，同时监听 Postgres 的通知。

架构效果：

• 对客户端来说，PgDog 本身看起来就是消息代理。
• 实际上，消息仍然存储在 Postgres 中（通过 NOTIFY 的语义）。
• 保留了事务语义：即使 NOTIFY 在某些情况下导致数据库崩溃（PgDog 团队修复了该问题），事务完整性依然保持。

这种“创造性的工程”让开发者可以继续使用 Postgres 原生的 pub/sub，无需引入额外组件。

核心问题 3：多线程 vs 多进程

现有方案的局限

• PgBouncer：单进程事件循环。为了利用多核，必须启动多个 PgBouncer 进程，并依赖 SO_REUSEPORT 实现端口共享。但每个进程拥有独立的连接池，客户端一旦连接某个进程，就无法切换。如果某个进程过载，其客户端全部卡住。
• RDS Proxy：支持“无服务器”自动缩放，但缩放需要时间，且控制平面复杂。

本质上，两者都要求你分片连接池——这增加了运维复杂度。

PgDog 的多线程模型

PgDog 基于 Tokio（Rust 异步运行时），使用多线程工作线程：

• 每个客户端由一个独立的异步任务处理。
• 任务数量随连接数线性扩展。
• 利用多核 CPU，单个 PgDog 进程可以处理更多客户端和更高 QPS。

优势：

1. 更高的连接利用率：一个进程可以服务更多客户端，减少对后端连接的需求。
2. 突发流量处理：无需等待自动缩放，多线程进程可以立即吸收查询突发。
3. 简化的运维手册：只需监控一个进程的指标和健康检查，无需处理 Linux 内核级别的 SO_REUSEPORT 或 AWS 控制平面。

总结与展望

PgDog 已经生产运行超过一年，峰值达到 200 万 QPS。它开源（AGPL 许可证），可部署在任何环境中。

核心哲学：不要强迫用户放弃 Postgres 的特性来使用连接池。SET、LISTEN/NOTIFY 是 Postgres 的标配，连接池器应该透明地支持它们，而不是成为“漏油抽象”。

对于正在考虑连接池的团队：

• 如果应用大量使用 SET 或 RLS，PgDog 是唯一能保留这些特性的选择。
• 如果使用 LISTEN/NOTIFY 作为轻量级消息队列，PgDog 让你无需迁移到外部系统。
• 如果追求高吞吐和低延迟，多线程模型比多进程分片更高效。

原文链接：https://pgdog.dev/blog/why-yet-another-connection-pooler