OpenAI 8 亿用户，一台 PostgreSQL 主库 + 50 个只读副本。
这……听起来像是在开玩笑？
但 OpenAI 刚发布的工程博客中写道：ChatGPT 背后的核心数据库，就是一个 PostgreSQL 主库加上近 50 个分布在全球各地的只读副本。
过去一年，他们的 PostgreSQL 负载增长了超过 10 倍，而且还在继续飙升。
裂缝初现
ChatGPT 发布后，流量以前所未有的速度增长。
为了应对，团队在应用层和数据库层都做了大量优化，纵向扩容（加大实例规格），横向扩展（增加只读副本）。
但问题总会找上门。
他们遇到的故障往往遵循同一个模式：上游某个问题导致数据库负载突然飙升，可能是缓存层故障导致的大规模缓存未命中，可能是昂贵的多表 JOIN 查询吃满了 CPU，也可能是新功能上线引发的写入风暴。
资源利用率一上去，查询延迟就跟着涨，请求开始超时。
然后重试机制又进一步放大负载，形成恶性循环，甚至可能拖垮整个 ChatGPT 和 API 服务。
而 PostgreSQL 在写负载高的时候确实有点吃力。
这主要是因为它的 MVCC（多版本并发控制）实现方式：更新一行数据，哪怕只改一个字段，整行都要复制一份新版本。写负载一高，写放大就很严重。读也跟着放大，因为查询得扫过多个版本（死元组）才能拿到最新数据。
MVCC 还带来了表膨胀、索引膨胀、索引维护开销增加、autovacuum 调优复杂等一系列头疼的问题。
如何扛住百万 QPS
为了缓解这些限制，OpenAI 把可分片的写密集型工作负载迁移到了 Azure Cosmos DB 这样的分片系统，同时优化应用逻辑，减少不必要的写入。
他们甚至不再允许在现有 PostgreSQL 部署中新增表：新工作负载默认走分片系统。
但 PostgreSQL 本身仍然是单主库、不分片的。
这是为什么呢？
因为分片现有的应用工作负载太复杂了，要改几百个应用端点，可能要花几个月甚至几年。而他们的工作负载主要是读密集型的，经过大量优化后，现有架构仍然有足够的余量支撑未来增长。
下面是他们做的一系列优化：
减轻主库负担
只有一个写入节点，单主架构没法扩展写入。写入峰值一来，主库很容易过载。
解决方案： 尽可能把读写负载都从主库卸下来。读流量尽量导向副本。写流量则迁移到分片系统。应用层也做了激进优化：修复了导致冗余写入的 bug，引入了延迟写入来平滑流量峰值。回填表字段时，严格限流，防止写压力过大。
查询优化
他们曾发现一个同时 JOIN 了 12 张表的查询，这个查询的流量峰值直接导致了过去的多次严重故障。
（12 张表 JOIN……不会是 GPT-3.5-nano 写的吧？
可以参考我的 CLAUDE.md 片段：
解决方案： 尽量避免复杂的多表 JOIN。如果必须 JOIN，考虑把查询拆开，把复杂的 JOIN 逻辑挪到应用层。很多问题查询是 ORM 框架生成的，所以要仔细审查 ORM 产出的 SQL。另外，配置 idle_in_transaction_session_timeout 这样的超时参数也很关键，防止长时间空闲的查询阻塞 autovacuum。
单点故障缓解
单主库意味着单点故障：主库挂了，整个服务就挂了。
解决方案： 大多数关键请求只涉及读查询。他们把这些读从主库卸载到副本，确保即使主库挂了，读请求仍然能继续服务。写操作会失败，但影响减小了：不再是 SEV0 级别的故障。
主库运行在高可用（HA）模式，配有热备节点，随时准备接管流量。Azure PostgreSQL 团队做了大量工作，确保即使在高负载下，故障切换也能安全可靠地完成。
工作负载隔离
经常遇到某些请求消耗过多资源，影响其他工作负载的情况：典型的「吵闹的邻居」问题。
解决方案： 把请求分成低优先级和高优先级两个层级，导向不同的实例。这样即使低优先级工作负载变得资源密集，也不会影响高优先级请求。不同产品和服务之间也采用同样的策略隔离。
连接池
每个实例都有最大连接数限制（Azure PostgreSQL 是 5000）。很容易耗尽连接或积累太多空闲连接。
解决方案： 部署 PgBouncer 作为代理层来池化数据库连接。
用 statement 或 transaction 池化模式，可以高效复用连接，大幅减少活跃客户端连接数。连接建立延迟也从平均 50 毫秒降到了 5 毫秒。代理、客户端和副本部署在同一区域，最小化网络开销。
每个只读副本都有自己的 Kubernetes 部署，运行多个 PgBouncer Pod。多个 Kubernetes 部署放在同一个 Kubernetes Service 后面，实现跨 Pod 的负载均衡。
缓存
缓存未命中率突然飙升，会导致大量读请求直接打到 PostgreSQL，吃满 CPU，拖慢用户请求。
解决方案： 实现缓存锁定（和租约）机制。当多个请求同时未命中同一个缓存 key 时，只有一个请求获得锁，去 PostgreSQL 取数据并回填缓存，其他请求等待缓存更新，而不是全部涌向数据库。这大幅减少了冗余数据库读取，保护系统免受级联负载峰值的冲击。
只读副本扩展
主库通过流复制把 WAL（Write Ahead Log）数据发送给每个只读副本。副本数量增加，主库就要向更多实例发送 WAL，网络带宽和 CPU 压力都会增加，导致副本延迟升高且不稳定。
解决方案： 他们在全球多个地理区域运行着近 50 个只读副本。但现有架构下，主库必须向每个副本流复制。
为此，他们正在与 Azure PostgreSQL 团队合作开发级联复制（Cascading Replication）：由中间副本把 WAL 中继给下游副本。这种方式可以扩展到超过 100 个副本，而不会压垮主库。这个功能目前还在测试中。
限流
流量突然飙升、昂贵查询激增、重试风暴都可能迅速耗尽 CPU、I/O、连接等关键资源，导致大范围服务降级。
解决方案： 在应用层、连接池、代理、查询等多个层面实现限流，防止突发流量压垮数据库实例。避免过短的重试间隔以防止重试风暴。ORM 层也增强了限流支持，必要时可以完全阻止特定的查询模式。
Schema 管理
即使是小的 schema 变更，比如修改列类型，也可能触发全表重写。
解决方案： 只允许轻量级 schema 变更，比如添加或删除不会触发全表重写的列。schema 变更强制执行 5 秒超时。允许并发创建和删除索引。现有 PostgreSQL 部署不允许添加新表——新功能需要的表必须放在 Azure Cosmos DB 这样的分片系统中。回填表字段时严格限流，虽然有时可能要花一周以上，但确保稳定性，不影响生产环境。
成果
这套方案证明了，通过正确的设计和优化，Azure PostgreSQL 可以扩展到支撑最大规模的生产工作负载。
PostgreSQL 处理着百万级 QPS 的读密集型工作负载，支撑着 OpenAI 最关键的产品：ChatGPT 和 API 平台。
近 50 个只读副本，复制延迟接近零，跨地理区域保持低延迟读取，并为未来增长预留了足够的容量空间。
生产环境中，他们持续保持着两位数毫秒级的 p99 客户端延迟和五个九的可用性。
过去 12 个月，只发生了一次 SEV-0 级别的 PostgreSQL 故障——
那是在 ChatGPT ImageGen 病毒式发布期间，写流量突然飙升超过 10 倍，一周内超过 1 亿新用户注册。
