将 PostgreSQL 扩展至支持 8 亿 ChatGPT 用户

PostgreSQL，这个开源关系型数据库的常青树，如今正作为OpenAI核心产品的基石，默默支撑着每秒数百万次的查询和8亿用户的访问。其架构颇为经典：一个主实例负责写入，配合遍布全球的近50个只读副本来应对海量读取。这套组合拳展现了PostgreSQL在应对读密集型负载时惊人的扩展潜力。当然，任何技术方案都有其边界，面对写入压力，团队也巧妙地借助了Azure Cosmos DB来分担可分片的写负载，并持续优化着查询、负载分流与高可用策略。

多年来，PostgreSQL一直是ChatGPT与OpenAI API等服务的核心数据引擎。随着用户规模呈指数级攀升，数据库面临的挑战也与日俱增。过去一年，其负载增长了超过10倍，且增长势头丝毫未减。

在持续升级基础设施以应对业务洪流的过程中，我们获得了一个关键洞察：PostgreSQL处理读密集型负载的能力，远比许多人想象的要强大。这个源自加州大学伯克利分校的系统，凭借一个Azure PostgreSQL灵活服务器主实例，以及部署在全球多个区域的近50个只读副本，成功扛住了全球流量的冲击。本文将分享OpenAI技术团队如何通过一系列扎实的工程优化，将PostgreSQL推向极限，并总结其中积累的宝贵经验。

初始架构的隐忧

ChatGPT发布后，流量以惊人的速度涌入。当时，团队在应用层和数据库层双管齐下，既通过提升硬件规格进行纵向扩展，也通过增加只读副本来横向扩展读取能力。这套架构在相当长一段时间内运行平稳，持续的优化也为未来的增长预留了空间。

单主架构竟能支撑OpenAI的庞大规模，听起来或许有些意外，但其落地过程绝非一帆风顺。团队曾多次遭遇因PostgreSQL过载引发的严重服务事件，其模式往往如出一辙：上游的某个问题——可能是缓存层故障导致的大范围缓存穿透，也可能是消耗大量CPU的复杂多表连接查询突然激增，或是新功能上线带来的“写入风暴”——会瞬间推高数据库负载。随着资源利用率飙升，查询延迟增加，请求开始超时。而后续涌入的重试流量，又会进一步加剧负载，形成一个自我强化的恶性循环，最终导致ChatGPT与API服务性能严重下降。

尽管PostgreSQL在处理读负载时扩展性良好，但在高写入流量期间，挑战依然严峻。这很大程度上源于其多版本并发控制（MVCC）的实现机制。简单来说，当一个查询需要更新某一行甚至其中一个字段时，PostgreSQL会复制整行数据以创建新版本。在高写入负载下，这种机制会导致显著的写入放大。同时，查询为了找到最新数据，可能需要扫描多个旧版本（即“死元组”），这又带来了读取放大。此外，MVCC还会引发表与索引膨胀、增加索引维护开销，并使自动清理（VACUUM）的调优变得复杂。

将PostgreSQL扩展至每秒数百万次查询

为了缓解上述限制、减轻主库的写入压力，团队采取了一个清晰的策略：将那些可以水平分片的写入密集型工作负载，逐步迁移至像Azure Cosmos DB这样的分片系统中。同时，优化应用逻辑，尽可能减少非必要的写入操作。作为一项纪律，新的工作负载默认不再使用当前的PostgreSQL部署，而是转向分片系统。

即便基础设施在不断演进，PostgreSQL本身仍保持未分片状态，由单个主实例处理所有写入。这背后的主要考量是成本与复杂性：对现有庞杂的应用工作负载进行分片改造，意味着需要修改数百个应用端点，其工程复杂度和耗时可能长达数月甚至数年。考虑到当前工作负载以读取为主，且已实施了大量优化，现有架构仍有充足的余量来支持流量持续增长。虽然未来不排除对PostgreSQL进行分片的可能性，但鉴于当前的扩展空间，这并非近期的优先事项。

那么，具体是如何应对挑战，并将PostgreSQL的查询处理能力推向每秒数百万次呢？以下将深入探讨几个关键的优化方向。

为主库负载减负

挑战： 单一写入节点是单主架构的天然瓶颈，无法横向扩展写入能力。剧烈的写入峰值可能迅速压垮主库，进而波及其支撑的所有服务。

解决方案： 核心思路是尽一切可能为主库“瘦身”。读取流量被最大限度地分流到只读副本。然而，部分读查询因其属于写事务的一部分而必须留在主库执行，对于这类查询，确保其高效运行、避免慢查询至关重要。在写入侧，可分片的写入负载已迁移至分片系统。对于那些更难分片但仍产生高写入的负载，迁移工作仍在持续进行。此外，团队积极优化应用以减少写入，例如修复导致冗余写入的程序缺陷，在适当场景引入延迟写入以平滑流量峰值。在进行大规模数据回填等操作时，也会强制执行严格的速率限制，防止产生过度的写入压力。

查询优化

挑战： 系统中存在一些高开销查询，过去，一旦这类查询的流量激增，便会大量挤占CPU资源，导致服务延迟甚至中断。

解决方案： 经验表明，少数几个高开销查询（尤其是涉及复杂多表连接的查询）就足以引发严重的服务劣化。因此，持续优化PostgreSQL查询、避免常见的OLTP反模式是一项必须坚持的工作。例如，团队曾定位到一个连接了12张表的极高开销查询，它的流量峰值正是过去几次高严重性服务事件的元凶。教训是深刻的：应尽可能避免复杂的多表连接。如果连接不可避免，可以考虑将查询拆分，将复杂的连接逻辑移至应用层处理。许多有问题的查询由对象关系映射（ORM）框架自动生成，因此仔细审查其生成的SQL是否符合预期，是开发中的必要环节。另外，PostgreSQL中长时间运行的空闲事务也会带来问题，配置如 idle_in_transaction_session_timeout 这样的超时参数，对于防止其阻塞关键的自动清理进程至关重要。

缓解单点故障

挑战： 读副本故障时，流量可以重新路由。但依赖单一写入节点意味着存在一个明显的单点故障——一旦主库宕机，所有写入操作都将中断。

解决方案： 幸运的是，大多数关键请求仅涉及读操作。为了缓解主库的单点故障风险，团队将这些读查询彻底从主库卸载到副本。这样，即使主库发生故障，这些只读请求仍可继续得到服务。虽然写操作会失败，但影响范围已被大幅缩小，通常不再构成最高级别的事故。

为了进一步减轻主库故障的影响，生产环境以高可用（HA）模式运行主库，并配备一个热备副本（保持同步、可随时接管流量）。当主库需要下线维护或发生意外宕机时，可以快速将备用副本提升为主库，最大限度减少停机时间。Azure PostgreSQL团队为此做了大量工作，确保即使在极高负载下，故障转移也能安全可靠。对于读副本故障，策略是在每个区域部署多个副本，并预留充足的容量余量，确保单个副本的失效不会导致整个区域的服务中断。

工作负载隔离

挑战： 经常遇到某些特定请求消耗不成比例资源的情况，导致同一数据库实例上的其他工作负载性能下降。例如，一个新上线的功能可能引入低效查询，大量消耗PostgreSQL的CPU，从而拖慢其他关键功能的请求。

解决方案： 团队在全球多个地理区域运行了近50个读副本以降低延迟。然而，在当前架构下，主库必须向每一个副本流式传输预写日志（WAL）。尽管目前通过使用超大型实例类型和高网络带宽尚能良好应对，但无限制地添加副本最终会压垮主库。为此，团队正与Azure PostgreSQL团队合作开发级联复制方案。简单来说，就是让中间副本充当“中继站”，将WAL日志传递给下游副本。这种方法有望将副本数量扩展到上百个，而不会让主库不堪重负。当然，这也会引入额外的运维复杂性，尤其是在故障转移的管理上。该功能目前仍在测试中，团队计划在确保其足够健壮并能安全进行故障转移后，再将其部署到生产环境。