# OpenAI 如何将 PostgreSQL 扩展至 800 万用户规模 > 剖析 OpenAI 单主节点加近 50 个跨地域读副本的 PostgreSQL 扩展路径，涵盖读流量卸载、连接池优化、缓存击穿防护与级联复制等关键工程实践。 ## 元数据 - 路径: /posts/2026/01/23/openai-postgresql-scaling-800m-users/ - 发布时间: 2026-01-23T18:47:34+08:00 - 分类: [systems](/categories/systems/) - 站点: https://blog.hotdry.top ## 正文 当业务规模从百万级跃升至亿级时，数据库扩展往往被视为一道难以逾越的鸿沟。传统观点认为，单一 PostgreSQL 实例难以支撑如此巨大的流量，水平分片几乎是必经之路。然而，OpenAI 的工程实践打破了这一认知：在过去一年间，其 PostgreSQL 负载增长超过十倍，却依然凭借单主节点加近五十个跨地域读副本的架构，支撑着八百万 ChatGPT 用户的百万级查询每秒吞吐量，同时保持低十位数毫秒的 p99 延迟和五个九的可用性。这一成绩的取得并非依赖运气，而是源于一系列经过严格验证的工程优化策略。 ## 架构选择：读流量全卸载，写流量外部化 OpenAI 的 PostgreSQL 架构核心思想简洁而务实：最大限度降低主节点的负载压力，使其始终保有充足的余量应对突发流量。具体而言，所有读流量都被路由至读副本，只有必须与写事务捆绑的查询才留在主节点执行。这一策略的关键前提是 ChatGPT 的工作负载具有极强的读密集特性——用户发起对话、获取历史记录、加载界面元素等操作绝大多数都是只读查询，写入操作主要集中在新消息保存、用户状态更新等相对低频的场景。 对于无法避免的写流量，OpenAI 采取了更为激进的策略：将可分片的写密集型工作负载迁移至 Azure Cosmos DB 等分布式系统。这意味着并非简单地在 PostgreSQL 内部进行优化，而是从架构层面将不适合单节点处理的负载剥离出去。剩下的写入操作往往是那些难以分片但量级可控的业务逻辑，它们仍然由 PostgreSQL 主节点处理，但通过应用层优化减少不必要的写入次数，例如修复导致重复写入的应用程序缺陷、引入延迟写入机制以平滑流量峰值、在进行大规模数据回填时严格限制写入速率等。 这种架构选择背后有着深刻的工程考量。PostgreSQL 的多版本并发控制实现对写密集型工作负载并不友好：当更新一行数据时，整个行会被复制以创建新版本，导致显著的写放大；同时，查询时需要扫描多个元组版本才能获取最新数据，增加读放大。在高写入压力下，还会引发表和索引膨胀、索引维护开销上升、autovacuum 调优复杂等一系列连锁问题。因此，与其强行在 PostgreSQL 内部解决这些问题，不如将这类负载迁移至专为高写入场景设计的分布式数据库。 ## 连接池与查询优化：夯实扩展根基 即便架构设计再精良，如果连接管理和查询执行效率低下，系统仍然会在压力下崩溃。OpenAI 在这一层面投入了大量精力，其中最具代表性的举措是部署 PgBouncer 作为数据库代理层。PgBouncer 运行在语句模式或事务模式下，能够高效复用数据库连接，极大降低活跃客户端连接数。实测数据显示，平均连接建立时间从五十毫秒降至五毫秒，降幅达十倍。这一优化不仅提升了响应速度，更显著降低了连接资源耗尽的风险。 在查询层面，OpenAI 的经验是必须对复杂 JOIN 操作保持高度警惕。他们曾发现一个涉及十二张表关联的查询在流量高峰期消耗大量 CPU，成为多次高严重性故障的罪魁祸首。解决方案是尽量避免在数据库层面进行复杂的多表关联，将这类逻辑移至应用层处理。对于必须保留的 JOIN 操作，需要仔细审查对象关系映射框架生成的 SQL，确保其行为符合预期。此外，配置如 `idle_in_transaction_session_timeout` 等超时参数对于防止长事务阻塞 autovacuum 至关重要。 连接数本身也是一个硬性约束。Azure PostgreSQL 的单实例最大连接数为五千，在高并发场景下极易耗尽。PgBouncer 的连接池机制是解决这一问题的主要手段，但配置必须谨慎，特别是空闲超时等参数需要精细调优。另一个值得关注的优化点是地域延迟：跨地域连接开销显著，因此应将代理层、应用程序和副本部署在同一地域，最大程度减少网络往返时间和连接占用时长。 ## 缓存击穿防护与流量整形 数据库层的优化固然重要，但缓存层的设计同样关乎整体系统的稳定性。OpenAI 使用缓存层承载大部分读流量，这在正常情况下能够有效保护数据库。然而，当缓存命中率意外下降时，大量请求会瞬间涌入数据库，形成缓存击穿风暴，瞬间耗尽 CPU 和连接资源。OpenAI 的解决方案是实现缓存锁机制：当多个请求在同一缓存键上发生缓存未命中时，只有最先获得锁的请求被允许访问数据库以重新填充缓存，其他请求则等待缓存更新完成而非同时冲击数据库。这一机制将冗余的数据库读取请求压缩至最小，显著降低了突发流量对数据库的压力。 流量整形是另一个关键环节。OpenAI 在应用层、连接池、代理层和查询层多个维度实施了速率限制，防止突发流量压垮数据库实例。更为重要的是，合理的重试间隔设计能够避免重试风暴——当请求失败时，过短的重试间隔会导致大量重试请求同时涌向数据库，加剧故障。他们还在对象关系映射层增加了速率限制支持，在必要时可以完全阻断特定的查询摘要，这是应对异常流量波峰的快速恢复手段。 ## 级联复制与高可用保障 当读副本数量接近五十个时，一个被忽视的问题开始显现：主节点需要向每个副本流式传输预写日志数据。随着副本数量增加，主节点的网络带宽和 CPU 压力持续上升，导致复制延迟波动加剧，系统的水平扩展能力受到制约。OpenAI 正在与 Azure 团队合作推进级联复制的实现，使中间副本能够将预写日志中继至下游副本，而非所有副本都直接连接主节点。这一方案有望在不对主节点造成额外压力的情况下，将副本数量扩展至上百个。当然，级联复制也带来了更复杂的故障转移管理问题，需要确保在各种异常场景下都能安全切换。 高可用设计同样精益求精。主节点以高可用模式运行，配备一个热备副本始终保持同步，可在主节点故障或需要维护时快速接管。虽然写操作仍然需要主节点，但读操作可以在主节点完全不可用的情况下继续提供服务，显著降低了单点故障的影响范围。每个地域部署多个副本并预留充足的容量冗余，确保单个副本故障不会导致地域级服务中断。 ## 变更管控与容量规划 数据库变更管理是容易被低估的风险点。即便看似微小的 Schema 变更，例如修改列类型，也可能触发整表重写，在大表上造成灾难性影响。OpenAI 的策略是严格限制仅允许轻量级 Schema 变更，例如添加或删除不触发表重写的列。所有 Schema 变更强制执行五秒超时，创建和删除索引必须使用并发模式。新增表的需求被引导至 Azure Cosmos DB 等分片系统而非 PostgreSQL。当需要进行大规模数据回填时，即便耗时可能超过一周，也必须严格限制写入速率以避免生产环境受到影响。 这些严格的变更管控措施背后是惨痛的教训。在过去十二个月中，OpenAI 仅发生一次 SEV-0 级别的 PostgreSQL 事故，恰好发生在 ChatGPT ImageGen 功能发布期间——一周内新增超过一亿用户，写流量瞬间激增十倍。这一案例既说明了流量突增的破坏力，也证明了经过充分优化的架构在面对极端场景时仍能保持弹性。 ## 工程启示 OpenAI 的实践表明，在读密集型工作负载下，PostgreSQL 可以通过精细的工程优化支撑远超预期的规模。关键不在于使用多么前沿的技术，而在于深刻理解系统瓶颈并针对性地逐一化解：连接池解决连接数瓶颈，读副本解决读吞吐瓶颈，缓存层解决数据库负载波动，级联复制解决副本扩展瓶颈，写流量外迁解决主节点写入瓶颈。这些优化措施相互配合，共同构建了一个稳定、高效、可扩展的数据层。 当然，这一路径并非放之四海而皆准。OpenAI 的工作负载具有读远多于写的特点，且其团队拥有深厚的数据库工程能力。对于读比例较低、查询复杂度更高或团队数据库经验有限的组织，单纯依靠优化单节点 PostgreSQL 可能并非最优解。但无论如何，OpenAI 的经验提供了一条值得参考的扩展路径，也为那些认为「上亿用户必须分片」的传统观念提供了有力的反例。 --- **参考资料** - OpenAI Engineering Blog: "Scaling PostgreSQL to power 800 million ChatGPT users" (2026年1月22日) ## 同分类近期文章 ### [好奇号火星车遍历可视化引擎：Web 端地形渲染与坐标映射实战](/posts/2026/04/09/curiosity-rover-traverse-visualization/) - 日期: 2026-04-09T02:50:12+08:00 - 分类: [systems](/categories/systems/) - 摘要: 基于好奇号2012年至今的原始Telemetry数据，解析交互式火星地形遍历可视化引擎的坐标转换、地形加载与交互控制技术实现。 ### [卡尔曼滤波器雷达状态估计：预测与更新的数学详解](/posts/2026/04/09/kalman-filter-radar-state-estimation/) - 日期: 2026-04-09T02:25:29+08:00 - 分类: [systems](/categories/systems/) - 摘要: 通过一维雷达跟踪飞机的实例，详细剖析卡尔曼滤波器的状态预测与测量更新数学过程，掌握传感器融合中的最优估计方法。 ### [数字存算一体架构加速NFA评估：1.27 fJ_B_transition 的硬件设计解析](/posts/2026/04/09/digital-cim-architecture-nfa-evaluation/) - 日期: 2026-04-09T02:02:48+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析GLVLSI 2025论文中的数字存算一体架构如何以1.27 fJ/B/transition的超低能耗加速非确定有限状态机评估，并给出工程落地的关键参数与监控要点。 ### [Darwin内核移植Wii硬件：PowerPC架构适配与驱动开发实战](/posts/2026/04/09/darwin-wii-kernel-porting/) - 日期: 2026-04-09T00:50:44+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析将macOS Darwin内核移植到Nintendo Wii的技术挑战，涵盖PowerPC 750CL适配、自定义引导加载器编写及IOKit驱动兼容性实现。 ### [Go-Bt 极简行为树库设计解析：节点组合、状态机与游戏 AI 工程实践](/posts/2026/04/09/go-bt-behavior-trees-minimalist-design/) - 日期: 2026-04-09T00:03:02+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析 go-bt 库的四大核心设计原则，探讨行为树与状态机在游戏 AI 中的工程化选择。