ChatGPT 存储架构大翻车，单租户方案彻底没戏

OpenAI 官方博客刚发了一篇长文，复盘怎么给 ChatGPT 扩容存储。评论区都在看热闹，原来支撑 1 billion 用户的底层架构，中间差点被几个吵闹邻居直接拖垮。

先说结论：

• Habitat 存储平台要支撑十亿用户和 500 petabytes 数据，经历了从单租户到多租户的反复横跳。
• 单租户太贵且难管，多租户又容易遇到吵闹邻居抢占资源，最后只能靠不断拆分容器来保护老系统。
• 给所有做大规模 SaaS 的团队提了个醒，别迷信单一架构，物理分区的吞吐量陷阱能直接搞崩核心登录流程。

讲真，看 OpenAI 基建团队踩坑也是一种享受。一开始，Habitat 平台是单租户模式，每个产品团队自己管自己的系统。这种模式好处是隔离性好，出了事影响范围小。但随着产品线和用户量暴增，这种模式太烧钱了。每个团队都要自己做容量规划，导致资源严重浪费，大家都在过度配置。

于是他们转向多租户，把控制权交给集中的数据库团队，指望靠集中管理提高效率。结果翻车了。多租户有个致命弱点：noisy-neighbor（吵闹邻居）。在 Phase I 阶段，他们用了默认的 Azure Cosmos DB container。逻辑分区键（比如 user_id 或 workspace_id）疯狂冲突。更惨的是物理分区限制，文档写着逻辑分区有 10K RU/s 的限制，但实际上物理分区才是硬约束。数据一多，物理分区分裂，每个子分区分到的吞吐量反而变少了。

结果就是，一个冷门功能的请求，直接把核心登录和注册流程给挤爆了。这种单纯因为存储增长就导致吞吐量下降的故障模式，简直让运维团队头皮发麻。你想啊，用户没变多，请求没变多，就因为是数据变大了，系统反而变慢了，这找谁说理去。

为了填这个坑，他们搞了 Phase II，尝试单租户隔离。给关键新用例单独开 Azure Cosmos DB container，每个容器有独立的物理分区。这确实解决了吵闹邻居的问题，不同业务线互不干扰。

但这又掉进了另一个坑。老系统还在默认容器里，压力越来越大。为了保住老系统不崩，团队只能疯狂给新服务开新容器。这其实是一种妥协，说明在超大规模下，绝对的隔离和绝对的共享都走不通。

这里给做 SaaS 的产品经理和架构师一个决策框架：当你的用户量从百万级跃升到十亿级，早期的架构红利会变成负债。评估多租户隔离级别时，别只看逻辑分区，必须摸清物理分区的吞吐量上限。如果你的核心交易流程和边缘功能混在一个物理分区里，一旦边缘功能流量暴涨，核心业务就会跟着陪葬。你需要为高频且对延迟敏感的核心链路，划定绝对的物理隔离边界。别为了省那点容器开销，把核心业务的命脉搭进去。

这事对运营和 HR 也有启发。你看 OpenAI 的基建团队，为了填这些坑，肯定在疯狂招人。原文末尾就挂了西雅图的软件工程师招聘链接：

)-seattle/

这说明什么？说明大厂在狂奔之后，必须回头还技术债。

对产品经理和研发来说，这里有一份避坑清单：第一，设计多租户系统时，必须把吵闹邻居的隔离级别想清楚，缓存 miss 的流量不能直接打到数据库，得加限流和租约。第二，监控物理分区的分裂情况，不要等数据量把吞吐量吃光了才想起来扩容，得写脚本同步容器吞吐量和物理分区数量。第三，老系统的迁移要趁早，别等默认容器变成垃圾场再想办法，该做数据迁移就得做，长痛不如短痛。

评论区唠唠
做大规模 SaaS，你选单租户保平安，还是多租户抠成本？