数据库又要挂了。

这是每一个后端工程师最不想听到的消息，尤其是在流量高峰期。连接数爆炸、主从延迟、分片逻辑写得像一坨意大利面——为了解决这些问题，我们通常得重构代码，甚至换掉整个架构。

但如果我告诉你，有个新工具叫 PgDog，号称能让你不改一行应用代码，就实现连接池、读写分离、甚至自动分片呢？听起来像是画大饼？但看完它的实现逻辑，说实话，我有点坐不住了。

它不只是另一个PgBouncer

如果你用 Postgres，你肯定知道 PgBouncer。它是行业标杆，但它也有让人抓狂的时候。

比如，它不太聪明。

PgBouncer 做连接池时，对于 SET 语句和一些启动参数的处理，经常会让不同配置的客户端互相打架。你得小心翼翼地维护会话状态，稍有不慎就会翻车。

**PgDog 不一样。**这个用 Rust 写的家伙，不仅能像 PgBouncer 一样做事务级的连接池，它还长了个“脑子”。它能解析 PostgreSQL 协议，理解你发来的每一条 SQL。

这意味着什么？

PgDog 能自动处理 SET 语句和启动选项。当不同参数的客户端共享同一个服务端连接时，它能确保会话状态被正确设置。甚至当你的应用崩了，留下一个烂尾的事务时，PgDog 会自动帮你回滚并重新同步连接，而不是像传统代理那样把连接搞坏。这就好比你以前请了个只会传话的保安（PgBouncer），现在请了个能帮你整理文件、甚至能帮你处理烂摊子的行政管家。

把分片做成“透明”的艺术

分片，是所有数据库架构师心中的痛。

AI配图

通常我们要么在业务层写死路由逻辑，要么上 Citus 这种重型插件。一旦分片逻辑写定，想改？那是脱层皮的事。

PgDog 的玩法很野：它在应用层做了分片。

通过内置的 PostgreSQL 原生解析器（pg_query），PgDog 能从 SQL 里直接提取分片键。看个素材里的例子，配置简单得让人怀疑人生：

[[databases]]
name = "prod"
host = "10.0.0.1"
shard = 0

[[databases]]
name = "prod"
host = "10.0.0.2"
shard = 1

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

配置好分片键是 user_id，接下来的事你就不用管了。

AI配图

-- user_id 是分片键，PgDog 自动路由到特定节点
SELECT * FROM users WHERE user_id = $1;

这还不是最骚的。

如果是跨分片查询怎么办？PgDog 会把查询发到所有分片，在内存里把结果拼好，再吐给客户端。对于客户端来说，它根本不知道后面有多少个分片，它以为自己还在连着单机数据库。

甚至，它还能处理 COPY 命令，自动把导入的数据行拆分到不同的分片里去。这种“无感”体验，对于想给老旧系统动手术的人来说，简直是救命稻草。## 零停机重分片，这是真的吗？

如果你问我 PgDog 最狠的一招是什么？我觉得是 Re-sharding（重分片）。

以前你想给现有的数据库加个分片，或者调整分片数量，基本等于停服维护。数据迁移、双写同步、切流，每一步都是坑。

PgDog 利用 PostgreSQL 的逻辑复制协议，搞出了一套“骚操作”：

  1. 搭好新的分片集群。
  2. PgDog 自动同步表结构。
  3. 开启数据同步，利用逻辑复制实时搬运数据。
  4. 最后，一个 MAINTENANCE OFF 指令，原子切换流量。整个过程，不需要什么复杂的分布式协调服务，也不需要停机。这种把“地雷”当“烟花”放的能力，确实有点东西。

老实讲，它并不完美

虽然 PgDog 看起来很美，但评论区里的大佬们也没闲着，问题都很尖锐。

AI配图

有人问：“如果我发了一个它处理不了的复杂查询怎么办？” 这是一个很现实的问题，跨分片查询的支持目前还在完善中，复杂的聚合、子查询可能会有坑。

还有人担心 复制延迟。读写分离时，如果主从延迟严重，读从库可能会读到旧数据。PgDog 虽然能路由，但它毕竟不是数据本身，这个问题还得靠底层的同步机制来扛。不过，也有来自生产环境的肯定。一位用户评论道：

"Happy pgdog user here... we're also running tests and positive about sharding..."
（我是 PgDog 的快乐用户……我们也在测试分片功能，目前看来很乐观……）

甚至有前 Citus 的开发者出来点赞，承认这些功能当年他们做了好几年才搞定，而 PgDog 的迭代速度惊人。## 开源协议里的“小心机”

最后聊聊它的开源协议：AGPL v3。

很多公司看到 AGPL 就想跑，觉得这玩意儿有“传染性”。PgDog 的开发者特意在文档里做了解释（或者说“辟谣”）。

简单来说，如果你只是内部使用 PgDog 代理你的数据库，你不需要开源你的任何代码。

AGPL 的限制主要针对那些“云厂商”——如果你想拿 PgDog 做成一个云服务卖给别人，那你对 PgDog 的修改就必须开源。这招挺聪明，既保护了开源项目的成果不被大厂白嫖，又让普通企业用户放心大胆地用。

结语

PgDog 想要做的事情，是在不改变应用代码的前提下，把 Postgres 的扩展性拉满。

它试图告诉我们：分片不一定非要侵入代码，负载均衡也不一定非要改架构。

虽然它还很年轻，某些复杂 SQL 的支持还在路上，但这种“把复杂留给中间件，把简单还给应用”的思路，确实值得点赞。

如果你正被 Postgres 的连接数或者分片搞得焦头烂额，或许，是时候去 GitHub 上牵这只“狗”回来遛遛了。

参考链接：
https://github.com/pgdogdev/pgdog