OpenAI 揭示了其核心产品 ChatGPT 背后的数据库架构，证明了 PostgreSQL 这款传统关系型数据库，在极致优化下足以支撑 8 亿用户和百万级 QPS 的海量服务。文章详细阐述了在单主库架构下，如何通过读写分离、性能调优和系统保护等策略，有效应对流量洪峰，为大规模数据库应用提供了极具价值的实践参考。
智能速览
采用“1 主 + 50 从”架构，强制读写分离以分散压力。
引入 PgBouncer 连接池，将连接延迟从 50ms 降至 5ms。
实现缓存锁定机制，防止缓存失效瞬间击垮数据库。
将写密集型任务迁移至分布式数据库，新功能默认不再使用 PostgreSQL。
在过去一年中，仅发生过一次与 PostgreSQL 相关的重大事故。
精华内容
面对用户量的爆炸式增长，OpenAI 的 PostgreSQL 架构经历了从濒临崩溃到稳定支撑的蜕变。以下是其为实现百万 QPS 和高可用性所采取的关键技术举措与深刻思考。
架构演进
OpenAI 采用“1 个主库 + 近 50 个只读副本”的架构，强制进行读写分离，将绝大部分读取请求导向副本，极大减轻了主库压力。虽然单主库存在写入瓶颈和单点故障风险，但鉴于现有工作负载 95% 以上为读取，且分片改造工程浩大，这一架构在现阶段仍是最高效的选择。为解决单点问题，主库运行在高可用模式，配备可随时接管的热备库；同时，所有可分片的写入密集型任务，如日志记录等，均已迁移至 Azure Cosmos DB 等分布式系统，从根本上为 PostgreSQL 减负。
性能调优
在性能层面，通过部署 PgBouncer 作为连接池代理，将平均连接建立时间从 50 毫秒显著降低至 5 毫秒，有效避免了连接耗尽问题。针对复杂的数据库查询，团队对曾导致服务宕机的 12 表联查等昂贵操作进行重构，将逻辑尽可能移至应用层处理，避免了数据库 CPU 被瞬间占满。同时，通过配置 `idle_in_transaction_session_timeout` 等参数，严格清理长时间空闲的查询，防止其阻塞关键的后台维护进程。
系统防护
为应对缓存失效或流量突增等异常情况，系统引入了多层防护机制。其中，“缓存锁定”策略是关键：当大量请求同时命中一个失效的缓存键时，仅允许一个请求穿透到数据库获取最新数据并回填缓存，其余请求则短暂等待，而非一拥而上地冲击数据库，从而有效避免了“惊群效应”导致的系统崩溃。此外，在请求端、应用端等多个层级实施了严格的速率限制，确保任何异常流量都无法冲垮数据库服务。
运维纪律
严格的运维纪律是保障稳定性的基石。OpenAI 强制要求所有 Schema 变更必须在 5 秒内完成，严禁任何可能导致全表锁定的重写操作。对于新增表的需求，默认要求使用 Cosmos DB 等分片系统，不再向现有的 PostgreSQL 集群添加新表。即使在为已有表添加字段时，也必须采用严格的速率限制进行回填，以平滑写入压力，这个过程可能持续一周以上，但有效避免了因数据库操作引发的生产事故。
成果展望
这一系列优化带来了显著的成果。PostgreSQL 集群稳定支撑着每秒数百万次的查询，P99 客户端延迟保持在低两位数毫秒级，实现了五个九（99.999%）的高可用性。在过去的 12 个月里，仅发生过一次因数据库引发的重大事故。展望未来，团队正与 Azure 合作测试级联复制技术，旨在解决主库向过多副本发送 WAL 日志的压力问题，为未来进一步扩展只读副本数量铺平道路。
OpenAI 的实践有力地证明了，通过精心的架构设计和严格的工程纪律，传统的关系型数据库 PostgreSQL 也能在超大规模场景下焕发新生。这为许多面临类似挑战的团队提供了宝贵的信心和参考。未来，随着业务复杂度的进一步提升，分片与无架构的界限是否会变得更加模糊？
