历史在重演
原文地址：https://richyen.com/postgres/2026/02/04/history_repeats_itself.html
时隔十五年，一些解决方案依然是优秀的解决方案
引言
OpenAI 最近分享了他们如何在 ChatGPT 平台上扩展至8 亿用户的故事。过去一年，随着人工智能的蓬勃发展，他们无疑面临了一些重大的扩展挑战，而我很好奇他们是如何应对的。概括来说，他们通过以下方案解决了以下问题：
- 减轻主库负载（将只读查询分流到副本）
- 查询优化（查询调优和配置超时参数，如
idle_in_transaction_session_timeout） - 单点故障缓解（配置热备以实现高可用）
- 工作负载隔离（实施了软件负载均衡方案）
- 连接池（部署了 pgBouncer）
- 缓存未命中（实现了缓存锁定机制）
- 扩展读副本（实施了级联复制）
- 资源耗尽（实施了速率限制，优化了 ORM）
- 模式变更导致的全表重写（执行了严格的 DML 策略）
诚然，要扩展到“每秒数百万次查询（QPS）”，他们投入了大量工作。我为他们团队实施这些方案以应对独特挑战而喝彩。👏👏👏
追忆往昔
阅读他们的文章时，我不禁想：哇，他们使用的一些解决方案和我们15 年前的没什么太大不同！十五年前，我是 Turnitin（当时叫 iParadigms）的首席 DBA。那时时代不同，社交媒体还未大规模兴起（当时 Instagram 还不存在！），我们都在本地部署，正从机械硬盘转向 SSD。当时，我们也同样面临着扩展至3000 QPS以服务美国、加拿大和英国师生数据的挑战。公司的创始人正在大力推广 Turnitin 进入中学和大学，而我们常常挣扎于只有“刚好足够”的资源来维持系统平稳运行。
有些东西（无需）改变
为了应对我们15 年前面临的挑战，我们采用了与 OpenAI 团队在2025 年设计的相似方案，即：
减轻主库负载
为了减轻主库负载，我们也实施了一个基于软件的解决方案，将只读查询发送到副本。我们用 Perl 编写了一个“复用器”（Multiplexor），监听所有传入的数据库流量（端口 5432），将包含 DML 查询的事务导向主库，而将其他查询发送到备用库。这确保了主库主要接收写流量（尽管部分读流量不可避免），并尽可能降低了 I/O。
连接池
为了确保每个数据库会话在排序、连接和聚合操作中获得最大资源，OpenAI 选择了pgBouncer作为连接池，并使用Kubernetes作为负载均衡机制。这很巧妙（我们那时没有 Kubernetes，但如果我再次担任 DBA 角色，我想我会采用它）。pgBouncer 是连接池的可靠选择；其高度可配置性和服务器会话管理能力，使 DBA 能够有效降低运维开销并保持高资源可用性。
工作负载隔离
为了隔离高优先级和低优先级的工作负载，OpenAI 实施了一个软件解决方案。他们没有具体说明，但我猜想这与他们的 Kubernetes 负载均衡配置有关。当时，我们也希望确保负载能在四个副本之间平衡，避免任何一个承受大部分读流量。为此，我们使用了haproxy，并配置它运行一些健康检查 Bash 脚本来决定流量路由。十五年过去了，haproxy 或许不再是热门词汇，但扎实的脚本和软件工程能力依然是维持系统运转的关键！
扩展读副本
OpenAI 团队详细介绍了他们如何利用级联复制作为扩展机制，扩展到“近50 个读副本”来处理其数百万 QPS。我猜测，除了给数据库带来巨大负载外，数百万 QPS 可能也让他们的网络团队在带宽消耗上有些头疼，不过这是题外话了……在 Turnitin，我们也采用了级联复制——不仅为了扩展读流量，也作为高可用性和灾难恢复的机制。通过将 WAL 文件传送到不同区域，我们能够拥有一个完全相同的数据库集群——1 个主库和 4 个备用库——而执行故障转移只需更改一个 CNAME 记录，将写流量导向新位置。之后，我们可以使用pg_rewind等工具将旧区域重新连接到新的主库区域。
结论
有趣且令人欣慰的是，15 年后，我们在 Turnitin 使用的一些相同方案，正被世界上最大的 PostgreSQL 部署之一所采用。这再次印证了一个事实：PostgreSQL 确实是“世界上最先进的开源关系型数据库”。PostgreSQL 社区人才济济，他们的专业知识深厚，代码健壮。即使是像pgBouncer这样的工具也极其可靠，足以应对超重负载、数百万 QPS 的工作场景。为 PostgreSQL 喝彩！ 🐘
)
