OpenAI 存储平台 Habitat 从 Python 到 Rust 的性能升级

2 名工程师、Codex 和一次 Rust 重写：OpenAI 存储平台 Habitat 的极限扩展史 Habitat 是 OpenAI 内部的在线存储平台：2024 年中它只是一个连接单个数据库的...

2 名工程师、Codex 和一次 Rust 重写：OpenAI 存储平台 Habitat 的极限扩展史 Habitat 是 OpenAI 内部的在线存储平台：2024 年中它只是一个连接单个数据库的 Python 客户端库，两年后成长为横跨约 40 个地理区域、服务超 10 亿周活用户、承载 500+ PB 数据、7000 万+ QPS 的分布式系统；其中 Python 版本在重写前峰值扛住了 2000 万 QPS，如今 Rust 版本已承接 95% 的生产流量。 openai.com/index/scaling-… # 演进的三个阶段 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 个并发流），并在中心位置做限流与熔断。 OpenAI Developers @OpenAIDevs Habitat is OpenAI's online storage platform that powers everything from ChatGPT to Codex. It has grown over 10x year over year. Before the Rust rewrite, its Python service handled more than 20 million requests per second at peak. 🔗 View Quoted Tweet 💬 0 🔄 0 ❤️ 2 👀 656 📊 1 ⚡