GitBook 如何为 30,000 个站点提供亚秒级内容更新

Source: Vercel Blog

概览

GitBook 在单个 Vercel 部署上托管 30,000 个文档站点，每月提供 1.2 亿次页面浏览。n8n、Nvidia 和 Zoom 等公司依赖该平台保持文档快速且实时更新。对于现代工程团队和编码代理而言，文档与其描述的生产代码同等关键，而 GitBook 正处于这一期望的核心。

发布模型与挑战

GitBook 的发布工作流类似于软件开发：提出更改、审查并合并。拥有 30,000 个独立管理的网站，每个站点都有自己的更新节奏，要让内容既快速又保持新鲜是一项复杂的工程难题。

在迁移到 Vercel 之前，编辑者会合并更改后访问已发布站点进行验证，却常常看到内容的旧版本。正如 GitBook 工程主管 Steven Hall 回忆的：

“我们的一个客户计划进行一次大型功能发布，但在发布当天，文档却落后于产品的其余部分。那一刻我们真正体会到，文档和代码一样重要，必须同步投入生产。”

Vercel 解决方案

已发布的内容前端运行在 Next.js 上，且为开源项目。当 Vercel 引入 use cache 指令时，团队看到了一个可以对单个数据获取函数进行缓存，而不是对完整页面响应进行缓存的方式。这种方法：

• 在请求之间去重昂贵的 API 调用。
• 使缓存行为直接在代码中可见，而不是隐藏在外部配置中。

基于标签的失效

在多租户系统中进行失效处理非常棘手——大范围的缓存清除会造成浪费。一个站点的拼写错误修复不应触发对其余 29,999 个站点的重新验证。

GitBook 已经拥有一个可靠的陈旧内容信号：合并事件（通过 GitBook 的应用、GitHub 或 GitLab）。团队构建了一个基于标签的失效系统，由这些事件触发：

1. 缓存的数据按其代表的内容单元打上标签。
2. 当合并发生时，仅重新验证受影响的标签。
3. 其他所有缓存数据保持不变。

因此，变更可在 ~300 ms 内全局可见。GitBook 每天处理 ≈ 40,000 次失效。

“除了构建我们自己的缓存之外，我不认为我们考虑过其他方案，” Hall 说。

AI 驱动流量的影响

AI 驱动的流量对 GitBook 文档在 2025 年同比增长 5 倍，目前已占 所有页面浏览量的 41 %。大型语言模型（LLMs）和自动化系统以编程方式爬取文档，将 GitBook 作为内部工具、SDK 和 AI 应用的真实来源。

这种转变改变了基础设施的计算方式：

• 人类读者通常每个站点只访问少量页面。
• AI 爬虫可以在一次会话中扫遍数百个站点的每个页面，命中人类很少触及的冷缓存路径。
• 将这种行为在 30,000 个站点上乘以后，就需要一个能够处理 高并发 和 不可预测流量 的缓存基础设施，同时在每次变更后保持即时一致性。

Hall 说明，缓存架构并不是专门为 AI 流量而选，但它恰好成为了合适的基础：

“无论是 AI 还是人类在阅读文档，我们都需要快速的文档。我们的目标接近 100 % 的缓存命中率。缓存命中意味着文档加载快，而快速的文档是 GitBook 的关键特性。”

未来展望

缓存基础设施持续演进。即将推出的功能，例如 adaptive documentation——根据读者定制内容——将为多租户缓存增加复杂性。随着 AI 流量不断攀升，30,000 个站点的请求量只会继续增长。

“各处的流量都在上升。工程师交付的内容越多，文档变更也越多。LLM 每天爬取的页面数量在增加。我们的主要目标是在扩展的同时，保持对延迟和可预测性的高标准，” Hall 说。

关于 GitBook

GitBook 是一个智能文档平台，已有超过 30,000 团队 使用它来大规模创建、发布和维护产品及开发者文档。它发布的内容前端是开源的，基于 Next.js 运行。