ChatGPT 十亿用户，存储怎么扛住？

OpenAI 最近公开了 Habitat 的演进过程：这套最初以 Python 库形态存在的存储系统，已经成长为支撑超过 10 亿 ChatGPT 用户、每秒处理 2200 万次请求的全球分布式平台。

这不是一次普通的基础设施升级。对 ChatGPT 来说，用户增长意味着模型推理请求增加，但真正难处理的，往往是推理之外的那部分状态：会话列表、用户偏好、记忆、任务进度、配置、权限、设备状态，以及各种需要跨请求读取和更新的产品数据。模型可以通过加机器扩容，存储却必须同时解决一致性、低延迟、跨地域访问和故障隔离。

OpenAI 在题为《Rapidly scaling online storage to serve over 1 billion ChatGPT users》的技术文章中，首次较完整地解释了 Habitat 如何从一个 Python 库演变为全球分布式存储平台。文章给出的关键指标是：Habitat 服务超过 10 亿 ChatGPT 用户，峰值处理能力达到每秒 2200 万次请求，也就是平均每秒约 2200 万次存储层操作。

我的判断是，Habitat 的价值不在于它提出了某种全新的数据库理论，而在于它展示了一个 AI 产品如何把“应用层存储”工程化到互联网超级应用的规模。对正在构建 AI Agent、协作工具和长上下文应用的开发者来说，这比又一个模型跑分更值得看。

Habitat 是什么：AI 产品的在线状态层

Habitat 是一套面向在线产品的分布式存储平台，用于为 ChatGPT 等高并发应用保存和读取用户状态。它并不等同于模型上下文，也不是简单的对象存储，而更接近位于产品服务与底层数据库之间的一层“在线状态层”。

所谓在线状态层，是指应用在处理一次请求时，需要快速访问、修改并复用的结构化数据集合。比如，用户打开 ChatGPT 时，系统可能需要读取最近会话、个性化设置、记忆条目和功能开关；当用户完成一次对话后，系统又需要写入会话元数据、更新使用状态，并让后续请求能够看到这些变化。

这类数据有三个特点。第一，单条数据通常不大，但访问次数极高；第二，读取远多于写入，却不能接受长时间的数据延迟；第三，数据访问和用户身份、区域、权限及业务逻辑紧密相关，不能只靠一个简单的键值缓存解决。

Habitat 最初是一个 Python library，开发者可以通过相对简单的接口访问持久化数据。随着 ChatGPT 的流量持续增长，它逐渐承担了更多职责：隐藏底层存储差异、处理数据分片与路由、协调多区域访问、吸收突发流量，并为上层服务提供更稳定的读写语义。

这条演进路径很有代表性。很多基础设施项目在早期只是某个团队为解决具体问题写的库，规模扩大后才被迫变成平台。库关注“怎么调用”，平台还必须回答“故障时怎么办”“跨区域怎么走”“升级如何兼容”“一个租户异常时如何不拖垮其他租户”。Habitat 的难点正是在后面这些问题上。

2200 万请求每秒，难点不只是吞吐量

每秒 2200 万次请求听起来像一个吞吐量指标，但它不能单独说明系统好不好。存储系统真正的挑战，是在峰值、故障和业务变化同时发生时，仍然保持可预测的延迟。

ChatGPT 的请求并不是均匀到达的。新模型、新功能、热点事件和移动端推送，都可能在短时间内把流量推高。更麻烦的是，一次用户请求可能触发多个后端读写操作；如果缓存失效，原本由缓存吸收的流量会突然穿透到底层；如果某个依赖变慢，上游服务又没有做好限流，就会产生大量并发等待。

因此，存储层要处理的不是“平均每秒多少次”，而是一组相互耦合的问题：

• 突发流量： 短时间流量陡增时，系统是否能够平滑吸收请求，而不是把压力直接传给数据库。
• 缓存失效： 大范围缓存未命中会制造瞬时读洪峰，热门键还可能引发缓存击穿。
• 写入风暴： 新功能上线或用户集中注册时，写请求可能在几分钟内达到平时的数倍。
• 重试放大： 请求超时后，客户端和服务端的重试会继续制造负载，最终形成“越慢越重试、越重试越慢”的循环。
• 跨地域延迟： 全球用户需要就近访问，但数据又不能因为地域切换而出现不可接受的不一致。
• 故障隔离： 一个产品功能或一个大租户出现异常时，不能把整个平台拖入故障。

这也是为什么“换一套更快的数据库”通常不是答案。数据库的性能只是系统上限的一部分，真正决定用户体验的还包括请求路由、缓存策略、连接池、超时设置、负载保护、复制机制和降级方案。

从单一后端到全球分布式平台

全球分布式存储平台，是通过多个地理区域部署数据服务并协调访问的系统。它的目标不是让每个请求都访问同一个全球数据库，而是让请求尽可能在本地完成，同时在必要时提供跨区域的数据同步和故障切换能力。

对于 ChatGPT 这类产品，本地化访问有直接收益。用户在亚洲发起的请求，如果每次都绕到北美读取数据，网络往返时间和跨洲链路抖动会进入用户感知；如果请求被路由到附近区域，存储层就有更多机会把延迟控制在稳定范围内。

但“就近访问”并不等于“每个区域各存一份、互不相干”。用户可能在手机、浏览器和桌面客户端之间切换，也可能在不同国家旅行。一个区域写入的数据，需要按照产品要求传播到其他区域；如果用户刚修改了设置，下一次请求读到旧版本，就可能出现功能开关回退、会话状态错乱或任务重复执行。

Habitat 的平台化意义，正在于把这些细节从业务代码中抽出来。上层产品不必为每一种数据类型单独实现路由、复制和故障处理，而是通过统一的存储抽象使用底层能力。这样做的代价是平台本身必须定义清楚数据模型、访问语义、错误处理和演进规则；收益则是新产品可以复用经过大规模流量验证的基础设施。

需要强调的是，全球分布式并不自动意味着强一致。不同数据对一致性的要求不同：用户账号权限可能要求更严格的读取保证，浏览历史或推荐偏好则可能允许短暂延迟。成熟的存储平台不会用一套一致性策略覆盖所有场景，而会根据数据重要性、更新频率和故障代价做取舍。

为什么重试会把一次故障变成系统事故

重试雪崩，是分布式系统在依赖变慢时由重复请求进一步放大故障的现象。它是 OpenAI 分享这类架构经验时最值得开发者警惕的部分。

假设底层存储平时能处理 100 万次请求，某个缓存集群短暂失效后，原本应该在缓存完成的请求全部打到底层。数据库开始变慢，部分请求在客户端超时；客户端随后重试，等于在原有流量之外又增加了一批请求。如果每个请求平均重试一次，压力可能接近翻倍；如果多个服务层级各自重试，放大倍数还会继续上升。

这个过程很像高速公路上的连环堵车：前方只是一个小故障，但后车不断刹车、变道和重新汇入，最终让整条道路失去通行能力。存储层的保护措施不能只关注正常状态，还要主动限制故障状态下的流量。

对 AI 应用开发者而言，至少有几条经验可以直接借鉴：

1. 为重试设置上限。 不要让一个请求无限重试；重试次数、总等待时间和可重试错误都应该有明确边界。
2. 使用指数退避和抖动。 让重试请求逐渐拉开时间，避免所有实例在同一时刻再次冲击后端。
3. 区分读写操作。 幂等读通常更适合重试，非幂等写入则必须有请求 ID 或幂等键，避免重复创建任务或重复扣除资源。
4. 让超时预算向下传递。 上游只剩 100 毫秒时，不能让下游继续等待 1 秒；否则请求会在各层堆积。
5. 为非关键数据设计降级路径。 推荐、统计和部分个性化数据读不到时，产品应尽量返回默认值，而不是让核心对话一起失败。

这些规则听起来基础，却经常被 AI 产品的快速迭代节奏打破。一个新 Agent 功能可能同时增加任务状态、工具调用记录和用户记忆写入，如果每一层都用“先写入，失败就重试”的方式处理，流量上升后很容易把存储变成系统瓶颈。

与 PostgreSQL 扩展路线的互补关系

Habitat 并不意味着 OpenAI 放弃 PostgreSQL，二者解决的是不同层次的问题。OpenAI 在 2026 年 1 月分享过 PostgreSQL 扩展实践：单个 Azure PostgreSQL 灵活服务器主实例配合分布在多个区域的近 50 个只读副本，支撑 8 亿 ChatGPT 用户，并为读密集型工作负载处理每秒数百万次查询。官方披露的生产指标包括低两位数毫秒级 P99 客户端延迟和 99.999% 可用性。

PostgreSQL 更像可靠的事实记录层，适合需要事务、查询和明确数据关系的业务；Habitat 则更像面向在线服务的访问与分布层，负责让海量请求以统一方式抵达合适的数据后端。两者可以组合，而不是二选一。

| 对比维度 | Habitat | PostgreSQL 扩展架构 | |---|---|---| | 主要定位 | 全球分布式在线存储平台 | 关系型数据库及其读扩展体系 | | 主要价值 | 统一访问、路由、分布与平台化能力 | 事务、关系查询与持久化事实记录 | | 典型压力 | 高频读写、跨区域访问、突发流量 | 读密集型查询、主库写入与副本复制 | | 已披露规模 | 超过 10 亿 ChatGPT 用户、2200 万请求/秒 | 8 亿用户、每秒数百万次查询 | | 关键风险 | 跨区域一致性、故障隔离、流量放大 | 主库过载、复制延迟、写入风暴 | | 适用场景 | 会话状态、用户偏好、在线产品数据 | 核心业务记录、关系查询、事务数据 |

从这个角度看，OpenAI 的路线并不是用某一种“神奇数据库”解决所有问题，而是把不同数据和不同访问模式拆开处理。能否拆得足够早、边界定义得足够清楚，往往比单纯追求某个组件的峰值跑分更重要。

AI Agent 会把存储问题再推高一轮

AI Agent 是能够理解目标、调用工具并持续推进任务的软件系统。与一次问答相比，Agent 会产生更多中间状态：计划、工具调用参数、执行结果、错误信息、重试记录、人工确认节点和最终产物。

这意味着未来的 AI 存储压力不只是“用户变多”，还包括单个用户的状态复杂度上升。一个普通聊天请求可能只需要读写少量元数据；一个持续数小时的研究或编码任务，则可能产生大量事件记录，并要求多个执行器共享最新状态。

Agent 对存储系统提出了三项更苛刻的要求。首先是可恢复性，任务不能因为某个执行节点重启就丢失进度；其次是幂等性，同一个工具调用不能因为网络抖动而执行两次；最后是可观测性，开发者需要知道状态在哪一步改变、哪个版本产生了错误。

因此，Habitat 这类平台对 AI 开发者的启发并不是“照搬某个架构”，而是尽早把状态管理当成产品核心能力。短期 Demo 可以把状态塞进进程内存或单个数据库表，长期产品则必须明确状态的生命周期、所有权、版本、复制范围和删除策略。

OpenAI 这次分享，哪些地方仍然值得保留判断

OpenAI 公布的 2200 万请求/秒是重要指标，但外部读者仍然需要区分“平台总吞吐量”和“单类业务的实际负载”。文章摘要没有完整披露请求的读写比例、单请求大小、P50/P95/P99 延迟分布、跨区域复制延迟、数据一致性等级以及故障演练结果。没有这些维度，单一吞吐数字不能直接用于和 DynamoDB、Cassandra、FoundationDB 或自建 KV 系统做公平对比。

同样，10 亿用户也需要结合使用频率理解。补充资料援引 Sensor Tower 对 2026 年 5 月 ChatGPT 全球月活跃 App 用户的估计；OpenAI 此前披露的口径则包括 2026 年 2 月超过 9 亿周活跃用户和 5000 万付费订阅者。月活、周活、App 用户、全平台用户并不是同一个统计口径，不能把它们简单相加。

但这些口径差异并不会削弱技术问题本身。无论最终用户数字是 8 亿、9 亿还是超过 10 亿，只要一个 AI 产品同时拥有全球流量、持续对话和快速功能迭代，在线存储就必须面对类似的峰值与故障挑战。

给开发者的结论：先设计故障，再设计功能

Habitat 最值得借鉴的经验，是把存储从“后端实现细节”提升为 AI 产品的可靠性边界。模型能力决定产品能做什么，存储架构决定产品在真实流量下能否持续做到。

如果你正在构建一个 AI Agent 或长上下文应用，建议在早期就回答以下问题：

• 哪些状态必须强一致，哪些状态允许最终一致？
• 用户重复提交或网络重试时，如何保证写入幂等？
• 缓存全部失效后，底层系统能承受多少分钟的峰值？
• 一个区域不可用时，请求会切到哪里，用户能接受多旧的数据？
• 非核心数据读取失败时，产品能否继续完成主任务？
• 如何记录每次状态变更，让一次 Agent 任务可以回放和恢复？
• 单个热门用户、热门任务或异常租户，是否会占满共享资源？

这些问题没有统一答案，但越晚回答，迁移成本越高。对小团队来说，直接复刻 OpenAI 的全球架构当然没有必要；然而，幂等写入、有限重试、超时预算、缓存击穿保护和可观测性，是从第一版就应该具备的能力。

OpenAI 分享 Habitat 的时间点也很有意味：截至 2026 年 9 月 11 日，AI 应用的竞争已经从“谁先接入模型”转向“谁能把模型稳定交付给足够多的人”。当 ChatGPT 从产品变成全球基础设施，存储不再是幕后配角，而是决定 AI 能否规模化运行的主舞台之一。

参考来源

1. OpenAI GitHub 官方组织页——OpenAI 开源项目与工程资料入口；本文关于 Habitat 的核心数字和演进结论以 OpenAI 官方技术文章为准。
2. GitHub——用于交叉了解分布式存储、缓存、复制和高并发系统的公开工程实现。
3. Juejin 掘金——国内开发者社区，可用于检索 PostgreSQL 扩展、分布式系统和 AI 基础设施相关技术讨论。

注：由于文章要求参考链接仅保留指定国内可访问域名，OpenAI 官方原文链接未在文末直接列出；文中涉及的 Habitat 规模、PostgreSQL 架构和用户数据均来自题目提供的 OpenAI 资料及补充材料，月活与周活等指标需注意统计口径差异。