OpenAI 用 PostgreSQL 扛起 8 亿用户级别流量

OpenAI 最近放出了一篇技术博客，详细拆解了他们是怎么把开源关系型数据库 **PostgreSQL 进行深度定制和规模化改造**，最终支撑起 ChatGPT 和 OpenAI API 全球高并发业务的。这件事直接刷新了业内对传统关系型数据库扩展能力的认知——原来 PostgreSQL 还能这么玩。 随着 ChatGPT 用户量一路狂飙，OpenAI 在过去一年里发现 PostgreSQL 的整体负载增长了 **超过 10 倍**。面对峰值高达每秒数百万查询（QPS）的流量，还要保持毫秒级响应延时，团队在数据库架构、运维策略和应用协同上做了一套系统性升级。 整体架构依然走的是稳健的 **单主节点（single-primary）+ 多地域只读副本集群** 路线：所有写操作集中到主库，全球范围内大约 **50 个地理分散的只读副本** 负责承接各类读请求。这么设计的好处是避开了分片带来的复杂性和一致性难题，同时又能高效扛住海量读取场景。 ## 关键优化举措 ### 1. 写负载剥离与精简 为了缓解主库写入瓶颈，OpenAI 把部分高吞吐、可水平扩展的写密集型任务，迁移到了专用分片存储（比如 Azure Cosmos DB）上。同时，在服务层主动收敛一些非必要的写入操作，主库的事务压力因此显著降低。 ### 2. 全面推行读写分离 只有那些必须与写事务强绑定的读操作，才留在主库执行；其余绝大多数读请求统统交给各地副本。这样一来，主节点的资源消耗被有效分流，性能瓶颈自然松绑。 ### 3. 连接复用与智能缓存协同 引入 PgBouncer 作为连接池中间件后，平均连接建立耗时从大约 50ms 降到了 5ms。再配合分级缓存机制（本地缓存 + 分布式缓存），成功防止了缓存失效风暴导致数据库瞬时过载的尴尬。 ### 4. 查询治理与资源分级管控 多表 JOIN 等高开销 SQL 被严格限制，复杂关联逻辑前置到应用层处理。通过资源隔离策略（比如独立实例或 cgroup 限流），后台分析类、低优先级请求与核心在线服务物理或逻辑隔离，杜绝了“噪声邻居”互相干扰。 ### 5. 主库高可用与快速故障恢复 主库部署在高可用 HA 架构下，配置了实时热备节点。一旦主节点异常，秒级内即可完成无缝切换，最大限度保障服务 SLA。 经过上述综合调优，OpenAI 的 PostgreSQL 集群交出了一份亮眼的成绩单： * 支撑 **百万至数百万 QPS 的稳定读取吞吐** * 实现 **全球各区域毫秒级访问延迟** * 达成 **99.999% 的服务可用性** * p99 延迟控制在 **十几毫秒以内** 在过去 12 个月运行周期中，只发生过一次 SEV-0 级别数据库事件——起因是 ImageGen 功能用户激增导致局部资源饱和。 这一实践有力印证了一点：**在严谨的工程方法论与精细化架构设计支撑下，PostgreSQL 完全能胜任超大规模生产环境的核心数据底座角色**。对于大多数还没走到必须分片那一步的团队来说，它提供了一条更可控、更成熟、性价比更高的技术演进路径。 后续，OpenAI 正在评估包括 PostgreSQL 原生分片（如 Citus 集成）、级联复制增强，以及异步复制链路优化等方向，目标进一步提升只读副本的扩展弹性与跨区域同步效率。