OpenAI Habitat 存储平台：2人用Codex重写Rust的极限扩展

2 名工程师、Codex 和一次 Rust 重写：OpenAI 存储平台 Habitat 的极限扩展史

Habitat 是 OpenAI 内部的在线存储平台：2024 年中它只是一个连接单个数据库的 Python 客户端库，两年后成长为横跨约 40 个地理区域、服务超 10 亿周活用户、承载 500+ PB 数据、7000 万+ QPS 的分布式系统；其中 Python 版本在重写前峰值扛住了 2000 万 QPS，如今 Rust 版本已承接 95% 的生产流量。 https://openai.com/index/scaling-storage-one-billion-users-part-one/

演进的三个阶段

1. Python 库（2024 年中）：产品工程师不需要关心 schema 查找、路由、鉴权、加密、序列化、连接池——底层数据存在 Azure Cosmos DB。因为没有强推，靠口碑在内部迅速流行。

2. Python 服务（2025 年中）：库的致命伤是升级需要协调几十个业务方滚动部署。文中给了一个很有说服力的案例：一次为缩小单区域故障影响面的路由变更，功能开关推了几天，影子流量验证又几天，修 bug 又几天，最后正要开启时，某个团队因无关原因回滚到了旧的有 bug 的客户端——恰好造成了那次本想避免的宕机。于是把 Habitat 抽成独立服务，换来部署、可观测性、安全策略（访问控制、审计日志）的单一控制点。

3. Rust 服务（2026 年 Q2）：由 2 名工程师 + Codex + GPT-5.5 完成全量重写。数据：CPU 效率提升 6 倍，内存效率提升 15 倍，平均和尾延迟均显著下降，几周内 Python 版将完全下线。

Python 撑到 2000 万 QPS 的三堂课

1. asyncio 调度延迟是尾延迟的主导因素。 asyncio 解决 I/O 并发但不解决 GIL 下的 CPU 并行；而 Habitat 除代理请求外还有压缩、加密、校验、影子请求、hedging 等 CPU 密集任务。他们用"定时调度后台任务并测量预期与实际执行的时间差"来实时实证测量事件循环延迟，发现高负载下抖动可达数百毫秒甚至数秒。对策：每进程只服务少量并发请求，然后海量横向扩展进程数。一个很典型的实战发现：Statsig 功能开关配置默认每分钟全量 JSON 解析一次且无抖动，叠加每 pod 8 个进程的架构，导致每分钟全 pod 集体卡顿——修法是缩小配置、拉长间隔、加 jitter。

2. 连接池 LIFO 复用引发“亚稳态故障”。 全文最精彩的一段。aiohttp 的 TCPConnector 默认 LIFO。突发流量中，越慢的过载服务器归还连接越晚，反而越容易被下次请求选中，形成正反馈，流量持续向已经挣扎的 pod 集中，直到重启才能恢复。把连接池改为 FIFO 即打破循环，还顺带降低了稳态负载方差。今天他们主要靠 Istio/Envoy 的服务端负载感知均衡从架构上规避此类问题。

3. 海量进程 = 下游连接风暴。 进程数多一个数量级后，普通日常部署的连接重建、或一个连接泄漏就能打爆 NAT 网关。解法同样是 Envoy：把 Python 的 HTTP/1 升级为 HTTP/2 复用，集中池化连接（文中示例：6 pod 各自维持峰值连接共 18 条，经 Envoy 收敛为 1 条 HTTP/2 连接上的 6 个并发流），并在中心位置做限流与熔断。