QPS 百万级也不分片？OpenAI 仅凭 6 招，让 PostgreSQL 扛住 8 亿用户，详解 OpenAI 的 PostgreSQL 极致优化之路

这篇文章介绍了 OpenAI 是如何将 ChatGPT 背后的 PostgreSQL 数据库扩展到能够支持 8 亿用户 和 每秒数百万次查询（QPS） 的。

最令人惊讶的细节是：他们并没有对 PostgreSQL 进行传统的“分库分表”（Sharding），而是通过极致的优化，依然维持着 “单主节点（Single Primary） + 50 个只读副本” 的架构。

一、 背景与痛点

ChatGPT 用户量爆炸增长（8亿用户），数据库面临巨大压力。虽然读数据（用户看历史记录）可以通过增加副本解决，但这带来了新问题：

1. 写不动了： 只有一个主节点负责写入，高峰期容易卡死。
2. “吵闹的邻居”： 某个新功能如果写代码写得烂，会把整个数据库拖慢，影响核心聊天功能。
3. 连接数爆表： 每一台服务器都想连数据库，数据库的连接数限制（5000个）瞬间被占满。
4. 缓存击穿： 如果缓存突然失效，成千上万的请求同时打到数据库，数据库会瞬间崩溃。

二、 OpenAI 的 6 个核心“大招”

1. 给写操作“减肥”（最关键的一步）

他们发现 PostgreSQL 的机制（MVCC）在处理高频写入时效率不高。

• 做法： 把那些写得特别频繁的数据（比如一些日志或频繁变动的状态）直接搬走，迁移到 Azure Cosmos DB 这种更适合分片的系统里。
• 结果： 留在 PostgreSQL 里的主要是读多写少的数据，给主节点大大减负。

2. “缓存锁”机制（防踩踏）

通常缓存失效时，会有 1 万个请求同时去查数据库（Cache Stampede）。

• 做法： OpenAI 设计了一个“锁”。当缓存失效，只有 第 1 个 请求被允许去查数据库，其他 9999 个请求乖乖等着。等第 1 个请求把数据拿回来填进缓存，大家再一起从缓存读。
• 通俗理解： 就像食堂开饭，以前是所有人一窝蜂冲进厨房抢饭；现在是派一个代表进去端饭，大家在门口排队等着吃。

3. 连接池 PgBouncer（数据库的“前台接待”）

数据库原本能处理的连接数有限。

• 做法： 部署 PgBouncer 作为代理。
• 效果： 它可以把几千个应用请求合并成少量的数据库连接。连接建立时间从 50ms 降到了 5ms。

4. 读写分离与“级联复制”

• 现状： 一个主节点要把数据同步给 50 个只读节点（Replica），主节点光是发数据（WAL日志）都快累死了。
• 未来大招： 正在测试 “级联复制”。即：主节点只发给几个“中队长”节点，再由“中队长”发给剩下的“小兵”节点，减轻主节点压力。

5. 隔离“吵闹的邻居”

• 做法： 把请求分为“高优先级”和“低优先级”。关键业务（如聊天）走专用通道，新功能或后台任务走另一条通道。即使新功能崩了，也不会影响大家和 ChatGPT 聊天。

6. 严苛的数据库纪律

• 禁止复杂查询： 以前有过一个 join 了 12 张表的查询差点把系统搞挂，现在严格禁止这种写法，复杂逻辑要在代码层解决。
• 改表限制： 修改数据库结构（Schema）的操作必须在 5秒内 完成，否则强制终止，绝不允许长时间锁表。

三、 总结

OpenAI 证明了，在还没走到极其复杂的“分库分表”之前，通过精细的工程优化（比如移走高频写、优化缓存策略、连接池管理），单节点的 PostgreSQL 依然能扛住世界级流量。

虽然他们也在计划未来做分片，但目前的架构已经做到了 99.999% 的可用性 和极低的延迟。