揭秘OpenAI存储系统Habitat：支撑10亿用户的架构实践

支撑10亿用户：OpenAI在线存储架构演进实录

OpenAI各类产品的每次交互——从登录、读取设置到启动ChatGPT会话，底层都需要执行多次数据检索。若检索延迟，用户体验便会变卡；若检索失败，服务甚至会直接瘫痪。

为确保产品快速可靠地访问数据，OpenAI构建了统一的在线存储平台Habitat。如今，Habitat在近40个全球区域中，以超过7000万次/秒的并发吞吐，支撑着每周超10亿用户的产品流量，管理着超500PB的数据规模。而在两年前，它还只是一个挂载在单一数据库上的简易Python客户端库。

面对每年超10倍的用户增长，工程团队并没有充裕的时间预先做完备的长线设计，而是选择在极限压榨现有技术栈性能的同时，争取宝贵时间夯实底层架构。

什么是Habitat？

Habitat的出发点非常纯粹：让产品研发人员彻底摆脱数据库运维心智负担。

最初，Habitat仅是一个轻量级Python库，产品工程师只需调用简单的读写API，无需关心底层数据是来自Azure Cosmos DB、缓存还是其他存储引擎。分片寻址、鉴权、数据加密、序列化与连接池管理等繁杂细节，均被封装在库内。

但随着微服务数量剧增，客户端库的架构缺陷逐渐暴露：协议变更与配置迭代的跨团队协同成本变得极其高昂。例如，为了做跨区域Cosmos DB容灾路由，需要耗费数天协调几十个服务同步发布，稍有配置回滚就会引发全链路故障。为了收敛运维半径并建立强一致的安全审计与访问控制，团队决定将Habitat彻底解耦为一个独立的在线微服务。

极限压榨Python服务的尾部延迟

将数据存储层重构成Python独立服务，在当时是一个带有策略性的“技术借债”选择。团队清楚Python服务在大吞吐场景下的CPU和内存开销高昂，但短期内它能最快解除业务阻塞，让核心API迅速成型。在极端高并发下，OpenAI主要通过以下方案治理长尾延迟：

1. 监控并削减asyncio事件循环阻塞

Python的asyncio擅长处理I/O密集型任务，但无法绕过GIL提供真正的CPU并行能力。Habitat在转发请求的同时，还需承担路由判断、压缩、加解密与校验等重度CPU计算任务。一旦事件循环被CPU任务长时间霸占，等待解析响应的协程便会排队延宕，引发严重的p99延迟尖刺。

团队通过周期性注入后台探测任务，实时度量事件循环的调度延迟。最终策略是：大幅压低每个Python进程允许承载的并发请求数，并采用横向堆叠海量Python Worker进程的方式分散负载。

2. 规避配置解析的CPU尖峰

上线初期，团队发现Statsig功能开关配置由各进程每分钟定时全量轮询解析一次，毫无抖动（jitter）补偿。在每个Pod运行多进程的架构下，瞬间的超大JSON解析会直接吃满CPU，使正在处理的在途请求全部被挂起。随后团队通过拆分按需加载的轻量配置、拉长刷新窗口并引入随机抖动，平息了这一风暴。

3. 连接池陷阱与亚稳态故障

在连接管理上，客户端连接池曾引发严重的“亚稳态故障”。Python底层aiohttp默认采用后进先出（LIFO）的连接复用策略，当突发流量来袭时，较慢的服务进程归还连接较晚，反而被后续请求频繁拾取，导致“越慢的节点被塞入越多请求”，直至雪崩。将连接复用改为先进先出（FIFO）打破了这一恶性循环。目前，该层已统一委托给Envoy和Istio进行智能负载均衡，并通过Envoy将HTTP/1汇聚为HTTP/2长连接复用，避免下行连接风暴击垮后端数据源。

刻意受限的NoSQL数据模型

Habitat能长期扛住大流量，关键在于其接口设计的“克制”。它摒弃了支持复杂Join和全表扫描的SQL接口，而是借鉴Facebook TAO系统，对外提供基于“对象-边（Object-Edge）”的简易NoSQL抽象。

这种设计将请求严格限制在恒定、可预测的计算成本内。对象及其直属边在存储物理分区上保持就近分布，但跨对象的图跳转并不在数据库端自动关联，避免了不可控的跨集群漫游查询。对于需要进行复杂分析与搜索的业务场景，Habitat通过变更数据捕获（CDC）机制，将数据近实时同步到Rockset等离线检索集群，实现OLTP与复杂分析的严格物理隔离。