OpenAI如何应对海量负载：PostgreSQL一主多从架构的极限挑战与实战优化

在2025年的PGConf.Dev全球开发者大会上，来自OpenAI的技术成员张伯翰（Bohan Zhang）进行了一场题为“将PostgreSQL伸缩至新阶段”的演讲。这场演讲为我们揭示了这家全球顶尖的AI公司如何在其核心系统中驾驭经典的开源关系型数据库。演讲者站在讲台上，身后的大屏幕清晰地展示着OpenAI的标志以及演讲的核心议题。

背景：PostgreSQL在OpenAI的核心地位

在OpenAI，PostgreSQL是绝大多数关键系统的基石。演讲幻灯片明确指出，如果PostgreSQL服务中断，许多关键功能将变得不可用。事实上，过去曾发生过多次与PostgreSQL相关的严重事件，对ChatGPT等核心服务造成了显著影响。

面对数亿活跃用户带来的海量请求，对数据库进行有效扩展是一项至关重要的任务。OpenAI长期在微软Azure云平台上运营，其架构采用了一个未经分片的主从复制模式：一个主库负责所有写入，搭配多个只读副本。

核心挑战：写入密集型负载的瓶颈

在“一主多读”的架构下，PostgreSQL的读扩展能力表现优异，真正的瓶颈在于写入。为了将这套架构推向极限，团队遇到了来自多方面的挑战。

其中，PostgreSQL的MVCC（多版本并发控制）设计在应对高写入负载时存在一些已知问题。在一场题为“Challenges in write-heavy workloads”的技术分享中，张伯翰和CMU教授Andy Pavlo曾对此进行过详细剖析。这些问题包括：

• 表与索引膨胀：频繁的更新和删除操作会导致物理存储空间无法被及时回收。
• 自动清理（Autovacuum）调优复杂：需要精细配置以平衡资源消耗和清理效率。
• 版本迭代开销：每次更新都会产生元组的新版本，带来额外的复制开销。
• 索引维护开销增加：索引需要为更多的行版本进行维护和可见性检查。

此外，扩展只读副本也并非易事。高写入负载会产生大量的WAL（预写日志）需要同步到副本，这会增加复制延迟。随着副本数量的增加，网络带宽甚至可能成为新的瓶颈，使问题进一步恶化。

实战优化措施：从负载控制到架构治理

为了应对上述挑战，OpenAI的Infra团队从多个层面实施了系统性的优化。

减轻主库负载

优化第一步是尽力降低主库的压力，抹平写入峰值。具体的策略包括：

• 迁移写入负载：将那些适合分片的、写入密集型的业务从PostgreSQL迁移到其他更适合的系统。
• 减少应用层无效写入：在应用层面减少不必要的写操作，团队甚至发现并修复了一些导致冗余写入的应用Bug。
• 使用惰性写入：在可能的情况下采用惰性写入策略，以平滑写入峰值。
• 设置回填限速：在批量回填数据字段时，实施速率限制，避免突发流量冲击。

同时，团队尽可能地将读查询从主库卸载到只读副本。对于那些由于事务一致性要求而必须留在主库的读查询，则确保其执行效率极高。

查询优化

数据库查询本身的效率至关重要。团队采取了以下措施：

• 避免长时间空闲查询：通过设置超时参数来终止长时间运行的查询或空闲事务，因为它们会阻塞自动清理进程并消耗资源。
  • 设置 idle_in_transaction_session_timeout
  • 设置 statement_timeout
  • 在客户端也配置相应的超时。
• 避免OLTP查询反模式：团队曾观察到包含多达12张表连接的复杂查询，此类查询的流量尖峰曾引发严重事件（SEV）。建议通过在应用层处理连接逻辑来避免昂贵的多表连接。同时，演讲特别指出，过度依赖ORM（对象关系映射）容易导致低效查询，使用时需格外谨慎。

治理单点故障

主库作为唯一的写入节点，是整个系统的单点故障源。如果它宕机，所有写入操作都将暂停。相比之下，多个只读副本提供了冗余——一个副本故障，应用仍可从其他副本读取。事实上，大多数关键请求是只读的，即使主库故障，它们也能从副本继续服务（被定义为SEV2级事件）。

为了进一步保障核心业务的稳定性，团队将请求按优先级分类。高优先级请求若不可用，对用户影响极大（可能导致SEV0级事件），而低优先级请求影响较小（SEV2）。因此，团队为高优先级请求分配了专用的只读副本，确保它们不会被低优先级请求的流量所影响。

严格的模式（Schema）管理

为了维持系统的稳定性，OpenAI对生产数据库的模式变更实施了严格管控：

• 仅允许轻量级变更：
  • 不允许创建新表或引入新的工作负载。
  • 允许添加或删除列（但有5秒超时限制），任何需要重写整张表的操作均被禁止。
  • 允许使用CONCURRENTLY选项添加或删除索引。
• 处理阻塞变更的长查询：长时间运行（例如超过1秒）的持续查询会阻塞模式变更，导致变更失败。解决方案是优化或将这些查询迁移到只读副本上执行。团队使用类似下面的查询来定位问题：

  SELECT * FROM pg_stat_activity WHERE query like ‘%table_name%’ and now() – query_start > interval ‘1 seconds’;

优化成果

经过一系列努力，OpenAI取得了显著的成果：

• 将Azure PostgreSQL扩展至支撑数百万QPS，为OpenAI的关键服务提供动力。
• 在未增加复制延迟的前提下，成功添加了数十个只读副本。
• 在全球分布的只读副本上保持了低延迟访问。
• 在过去9个月中，仅发生一起与PostgreSQL相关的SEV-0级严重事故。
• 为未来的业务增长预留了充足的能力空间。

张伯翰在演讲总结中强调：“在OpenAI，我们通过一主多读的非分片架构，证明了PostgreSQL即使在面对海量读负载时也能实现卓越的扩展。”

故障案例深度分析

除了通用优化，演讲还分享了两个具体的故障案例。

案例一：缓存击穿引发的雪崩
这个案例描述了一个恶性循环：当Redis缓存出现问题时，导致缓存命中率下降，大量请求直接穿透到PostgreSQL，使其负载激增。这进而导致应用请求变慢或超时，触发客户端重试，产生更多请求，进一步加剧数据库压力。最终的解决方案是在PostgreSQL和应用代理层面实施速率限制，并在应用过载时主动丢弃部分请求。

案例二：写入尖峰触发的WAL发送器Bug
在一次写入尖峰导致主库CPU使用率飙升后，即使通过限速使主库CPU恢复正常，但只读副本的延迟仍在持续增加。经过排查，发现问题根源有三：

1. 主库的网络带宽已达到饱和。
2. 部分副本的磁盘IOPS达到饱和。
3. 一个WAL发送器中的Bug：当参数 async_standbys_wait_for_sync_replication 被启用时，一个缺陷会导致WAL发送器进入高CPU消耗的自旋循环，而不是有效地向副本流式传输WAL日志。
   团队通过升级实例规格/网络限額、调整网络设置以及修复该Bug解决了问题。

对PostgreSQL社区的功能诉求

基于在极限场景下的运维经验，OpenAI也向PostgreSQL社区提出了几点功能需求：

1. “禁用”索引功能：未使用的索引会增加维护成本和写放大。团队希望先“禁用”索引以观察性能，确认无误后再永久删除，以最小化风险。但目前PostgreSQL不支持直接禁用索引，只能删除后手动重建，而重建大索引非常耗时。
2. 增强可观测性：
   • pg_stat_statements 目前只提供每个查询模板的平均延迟，无法直接获取P95、P99等百分位延迟指标。团队希望它能提供直方图或百分位延迟等更多信息。
   • 希望PostgreSQL能够存储模式变更事件的历史记录，例如添加/删除列或索引等DDL操作。
3. 监控视图语义的澄清：团队发现一些处于active状态、等待事件为ClientRead的查询会持续运行数小时。由于状态是active而非idle_in_transaction，它们不会被事务空闲超时设置所终止。这是一个Bug吗？如果不是，如何自动终止此类查询？
4. 更智能的默认参数调优：PostgreSQL的默认配置参数值众所周知的保守。团队希望看到基于启发式的更好默认值，以及基于工作负载的自适应调优（例如自动清理）。像AWS RDS、Azure Database for PostgreSQL这样的云服务商已经提供了更好的默认值，而Google AlloyDB则实现了自适应的自动清理调优。

扩展视角：来自资深实践者的评论与答疑

本次演讲的翻译与点评者冯若航（老冯）基于自身在超大规模互联网公司管理PostgreSQL的经验，对OpenAI的实践和诉求进行了深度解读。

他认为，OpenAI遇到的挑战和采取的优化手段，在追求极致性能与稳定性的互联网场景中具有普遍性。OpenAI的强大之处在于，在顶级的硬件和云服务（Azure PostgreSQL）支持下，他们通过精湛的架构设计与精细的运维，实现了用一套未分片的PostgreSQL集群支撑起整个核心业务，这本身就是对关系数据库扩展能力的有力证明。

对于OpenAI提出的功能需求，老冯指出，其中许多在PostgreSQL生态中已有替代解决方案，但可能受限于托管数据库（RDS）的服务权限而无法使用：

• 禁用索引：可通过超级用户权限更新pg_index系统表中的indisvalid字段实现。更根本的解决方案是通过监控（如使用pg_stat_user_indexes）长期确认索引无人使用后再删除。
• 可观测性：扩展pg_stat_monitor可提供百分位延迟指标；也可通过eBPF旁路采集或在应用层DAL中添加监控。
• 模式变更记录：通过设置log_statement = ‘ddl’记录日志，或使用pgaudit扩展、CREATE EVENT TRIGGER以及pg_ddl_historization等扩展实现，但这些通常需要超级用户权限。
• 监控视图语义：State = active且WaitEvent = ClientRead可能发生在COPY FROM STDIN等待输入等场景。更通用的兜底方案是在负载均衡器（如HAProxy）或连接池层面设置连接最大生命周期，主动切断超时连接。
• 默认参数：保守的默认值确保了最广泛的兼容性，更优的初始化配置应由部署工具（如云RDS服务或Pigsty这类开源解决方案）根据硬件规格动态提供。

老冯的讨论揭示了一个深层次问题：许多极限场景下的优化挑战，并非源于PostgreSQL内核能力的不足，而是受限于托管数据库服务的抽象层。这也引发了关于在云上使用IaaS资源自建数据库集群以获取更高灵活性和控制权的思考。

参考资料

[1] OpenAI：将PostgreSQL伸缩至新阶段， 微信公众号：mp.weixin.qq.com/s/ykrasJ2UeKZAMtHCmtG93Q

版权声明：本文由 云栈社区 整理发布，版权归原作者所有。