PgDog 大规模 PostgreSQL 连接池与分片路由：Rust 协议级代理的工程实践

PgDog 是一个用 Rust 编写的 PostgreSQL 协议级代理，近期获得融资后正加速推进其连接池、负载均衡与分片路由能力的生产化落地。与 PgBouncer 等传统连接池工具不同，PgDog 在协议层实现了完整的 SQL 解析与路由决策，能够在不修改应用代码的前提下，为 PostgreSQL 集群提供水平扩展能力。目前已有 Modal、Ramp、Span 等公司将 PgDog 部署于生产环境，支撑超过 10TB 的分片数据与每秒百万级查询。

事务级连接池：突破连接数瓶颈

PostgreSQL 的架构特性决定了每个连接都会消耗独立的进程资源，当客户端数量达到数万级别时，连接开销会迅速成为性能瓶颈。PgDog 采用事务级连接池（Transaction Pooling）模式，允许将数万个客户端连接复用到少量的后端数据库连接上。

PgDog 的事务池实现解决了传统方案中的几个关键限制。首先，它完整支持 SET 命令、advisory locks 和 LISTEN/NOTIFY 等会话级特性，而无需将连接固定（connection pinning）到特定客户端。这一能力得益于 PgDog 在连接复用时对会话状态的精确追踪与恢复。其次，PgDog 能够自动处理应用崩溃后的废弃事务回滚，并在连接异常时执行重新同步，避免后端连接被污染。

在性能层面，PgDog 基于 Tokio 异步运行时与 bytes crate 构建，单机每线程可处理超过 5 万事务每秒。配置层面，default_pool_size 参数控制每个数据库的默认连接池大小，建议根据后端 PostgreSQL 实例的 max_connections 与预期并发量进行调优。对于高并发场景，可采用多线程部署配合 least active connections 负载均衡策略，将查询均匀分散到多个 PgDog 实例。

智能读写分离与故障转移

PgDog 在应用层（OSI 第 7 层）实现负载均衡，通过集成 pg_query 库使用 PostgreSQL 原生解析器分析 SQL 语句，自动识别写入操作（INSERT、UPDATE、DELETE、CREATE 等）并路由至主库，将 SELECT 查询分发到只读副本。

配置读写分离时，需为同一数据库配置多个后端节点并标注角色：

[[databases]]
name = "prod"
host = "10.0.0.1"
role = "primary"

[[databases]]
name = "prod"
host = "10.0.0.2"
role = "replica"

PgDog 支持轮询（round robin）、随机（random）和最少活跃连接（least active connections）三种负载均衡策略。对于只读事务，可通过 BEGIN READ ONLY 语法显式声明，PgDog 会将其路由至副本节点执行。

故障检测方面，PgDog 维护实时的健康检查列表，当节点未通过健康检查时会被自动剔除出活跃池。启用 role = "auto" 并配置 lsn_check_delay 参数后，PgDog 可持续监控复制延迟，在主库故障时自动将写流量切换至新的主节点。这一机制可与 Patroni 等高可用编排工具协同工作，实现 graceful failover。

分片路由与跨分片事务

PgDog 的分片架构支持 HASH、LIST、RANGE 三种分区策略，算法直接复用 PostgreSQL 源码以确保与 postgres_fdw 的行为一致性。分片配置通过 sharded_tables 区块声明分片键：

[[sharded_tables]]
database = "prod"
column = "tenant_id"

对于包含分片键的查询，PgDog 计算目标分片并将请求路由至对应节点，实现单分片 OLTP 性能。对于聚合查询或不含分片键的跨分片操作，PgDog 采用 scatter-gather 模式并行执行于所有分片，在内存中合并结果后返回客户端。目前支持的跨分片操作包括 COUNT()、SUM()、AVG()、MIN()、MAX()、GROUP BY、ORDER BY 等。

跨分片事务的一致性保障是分布式数据库的核心挑战。PgDog 采用 PostgreSQL 原生两阶段提交（2PC）协议实现跨分片事务的原子性。当客户端发送 COMMIT 时，PgDog 自动代理执行 PREPARE TRANSACTION 与 COMMIT PREPARED 流程。若客户端断开连接或节点崩溃，PgDog 会根据事务阶段自动执行回滚或提交恢复，确保数据一致性。

此外，PgDog 支持在线分片键更新（UPDATE 修改分片键字段），底层自动转换为 SELECT + INSERT + DELETE 三步骤执行。多行 INSERT 也会被自动拆分为单条语句分发到对应分片，配合 pgdog.unique_id() 函数生成全局唯一的 64 位整数主键，避免 UUID 带来的索引膨胀问题。

零停机重分片与运维策略

PgDog 内置逻辑复制协议支持，可在不停机的情况下完成数据重分片。其标准流程包含五个步骤：首先创建目标分片集群并执行 schema-sync 复制表结构；随后启动 data-sync 利用逻辑复制并行迁移数据；数据同步期间持续捕获增量变更；待数据接近一致时执行 schema-sync --data-sync-complete 创建二级索引；最后通过 MAINTENANCE ON → RELOAD → MAINTENANCE OFF 序列完成原子流量切换。

多节点部署时，RELOAD 命令不会立即恢复流量，而是等待 MAINTENANCE OFF 统一生效，确保所有 PgDog 实例在恢复查询前持有相同配置，无需依赖 etcd 或 ZooKeeper 等外部协调服务。

监控方面，PgDog 提供 PgBouncer 风格的 admin 数据库、OpenMetrics 端点以及 OTEL 遥测推送三种接口。建议生产环境配置复制延迟、连接池利用率、跨分片查询比例等关键指标的告警阈值，并结合慢查询日志持续优化路由策略。

部署建议与参数调优

对于生产环境部署，建议从以下维度进行配置：连接池大小设置为后端 max_connections 的 10%-20%，预留足够余量应对突发流量；启用 tls_verify 并配置 SCRAM-SHA-256 认证；对于 AWS RDS 或 Azure 托管实例，可配置 server_auth = "rds_iam" 或 "azure_workload_identity" 实现免密码认证。

PgDog 的 AGPL v3 许可证允许内部自由使用与私有修改，适合作为基础设施层组件部署。随着项目获得融资加速发展，其分片能力与生态集成将持续完善，为 PostgreSQL 的水平扩展提供更具竞争力的开源方案。

参考来源

• PgDog 官方文档与 GitHub 仓库：https://pgdog.dev, https://github.com/pgdogdev/pgdog
• PgDog 融资公告：https://pgdog.dev/blog/pgdog-is-funded

systems