给 10 亿人存对话记录，第二篇讲的是什么

聊天记录这东西，单看一个人没几 KB，乘以十亿用户就成了另一回事。10 月 23 日，OpenAI 工程博客发布了存储扩容系列的第二篇（第一篇是 9 月发的），专讲底层存储怎么扛住超过 10 亿用户的对话读写。这是厂商自述，但工程账算得很实在：哪些阶段出过什么事故、怎么改的、代价是什么，都摊开写了。文章结尾还预告了为「下一个十亿用户」自研存储系统的计划，值得连着看。

一、发生了什么

据 OpenAI 工程博客，承载对话存储的内部平台叫 Habitat，底层用 Azure Cosmos DB：数据总量超 500 PB，最大的单个账户存了数十 PB，每秒承受超 2000 万次请求，覆盖 40 个地理区域，官方称他们是在这个规模上用这套数据库的唯一公司。读取占了九成以上流量，为此全局读取延迟从约 120 毫秒压到约 10 毫秒。文章的主体是三阶段演进：第一阶段所有租户挤在共享容器里，吃尽嘈杂邻居的苦——一个边缘功能的负载能拖垮登录流程；第二阶段改成每家独立容器，隔离解决了，新业务上线忘了预留容量，团队就得临时进作战室救火；第三阶段回到默认多租户，加上热键限流、分级服务和改进的弹性模式，几个月没再出容量规划事故。数据同步靠变更数据流，每秒处理数百万条变更，流进 100 多个消息主题。2026 年的重点优化还包括：把服务代码从 Python 重写成 Rust，以及借鉴 Meta 的缓存方案做集成式分布式缓存。

二、跟你有什么关系

做后端架构的人：三阶段踩的坑——共享资源被拖垮、独立资源容量失控——几乎是所有多租户系统的必经之路，这篇等于别人交过学费的路线图。选云数据库的团队：厂商与客户联合值班、共享仪表盘的共管模式，值得写进你跟云厂商的谈判清单。普通用户：读取延迟降 12 倍这种优化，最终体现在对话列表秒开这种细节上。

三、怎么判断

1. 看架构演进顺序而不是单点技巧。先隔离、再弹性、最后共享优化，跳步走往往要还债，评估自家系统处在哪个阶段。
2. 关注「读取占九成」这个比例。多数聊天类产品读写严重失衡，优化方向应该是缓存和就近复制，而不是无脑扩写库。
3. 自述数据留个心眼。2000 万 QPS、「唯一一家」这类说法是厂商口径，没有第三方可验证，当作工程参考即可。

四、三个别信的说法

「换更贵的数据库就能解决扩展问题。」 文章里真正的转折不是换产品，是租户模型和容量策略的反复调整。架构问题买不来，只能演进来。

「Python 太慢必须全重写成 Rust。」 这次重写只针对服务代理层的热路径，作用是降低开销。大部分业务代码的瓶颈在数据访问模式，语言不是第一变量。

「十亿用户的方案小公司可以直接抄。」 500 PB、40 区域的基础设施没有普适性，能带走的是演进思路和踩坑清单，不是配置清单。

五、一句话结论

存储扩容没有银弹，只有一轮轮「先能用、再好用、后省钱」的迭代——这句官方设计哲学，比任何单点技巧都值钱。

信息来源

• OpenAI 工程博客：为超 10 亿用户扩容在线存储（第二篇）（2026-10-23）

功能与价格以官方公告为准。本文写于 2026 年 10 月 24 日。