Vercel 统一运行时缓存：Data Cache 并入 Runtime Cache

Vercel 正在把分散的缓存产品合并成一套。Data Cache 被并入 Runtime Cache，开发者不再需要在两套缓存体系之间做选择。对使用 Next.js fetch 缓存或 unstable_cache 的项目来说，代码无需改动，但计费和存储配额会发生变化。

为什么需要 Runtime Cache

Data Cache 最初是为 Next.js App Router 设计的数据缓存服务，支撑 fetch 缓存和 unstable_cache。它和 CDN 缓存的分工很明确：CDN 缓存完整的 HTTP 响应，Data Cache 缓存应用生成响应时用到的数据。一个商品页可以复用缓存的产品目录数据，同时为每位访客渲染个性化内容。

问题在于这套能力长期与 Next.js 绑定。Vercel 随后推出 Runtime Cache，提供 @vercel/functions 中的 getCache 直接 API，让 SvelteKit、Nuxt 等框架也能使用，覆盖路由中间件中的功能开关查询、构建期 CMS 内容缓存等场景。框架也可以自行封装这层 API——Next.js 的 'use cache: remote' 就是通过 Runtime Cache API 缓存函数和组件输出的。

Data Cache 与 CDN 缓存的分工需要从缓存对象层级来理解。CDN 缓存（Vercel 上即边缘网络缓存）存储的是完整的 HTTP 响应，键通常是 URL 加请求头，命中时整个响应直接回传，应用服务器完全不参与。Data Cache 存储的则是应用渲染过程中产生的中间数据，例如数据库查询结果、CMS 接口返回的 JSON、计算结果等，它对最终 HTML 没有直接控制权。两者可以叠加：一次请求可能先命中 CDN 拿到成品页面，也可能 CDN 未命中、进入函数后命中 Data Cache 复用数据而只重新渲染个性化部分。正因层级不同，合并后的 Runtime Cache 并不会取代 CDN 缓存，前者解决“数据复用”，后者解决“响应复用”。

Runtime Cache 的工作机制

Runtime Cache 的底层是一个由众多团队共享的分布式缓存服务：Go API 处理请求，每个 Vercel 区域背后是 Redis 集群。据 Vercel 披露，该服务每小时处理超过 4.4 亿次读取、搬运超过 18 TB 数据。

缓存按区域隔离。命中时只需一次往返，认证由 Vercel 用短期凭证处理，开发者不用管理 API 密钥。未命中时，应用或框架自行获取或计算值，再写入本区域缓存，服务不会跨区域查找副本。

失效机制值得单独说。每个缓存条目记录标签和写入时间，读取时会在同区域的独立标签存储中核对这些标签的失效时间戳。如果某个标签在条目写入后被失效，该条目即视为过期。这意味着失效一个 catalog 标签只需写入一个时间戳，哪怕上百万条目共享该标签，也不必逐条删除。标签基础设施与 CDN 共用，失效时间戳通过全局推送管道分发，通常几百毫秒内到达其他区域。

标签失效（tag-based invalidation） 是一种与“按键删除”相对的缓存失效范式。传统做法是失效时遍历或记录所有相关 key 再逐一删除，条目规模大时成本高且容易遗漏。标签失效给每个条目附加一个或多个标签名，同时维护一份独立的“标签→最近失效时间戳”映射。读取时比较条目写入时间与该标签的失效时间戳，写入更早即判定过期。这样失效操作从 O(条目数) 降为 O(标签数)，只需更新一个时间戳。代价是每次读取多一次时间戳核对，这也是文中“判断条目是否新鲜会给每次命中增加一次依赖调用”的来源；而熔断机制正是为了在标签存储变慢时跳过这次核对。

近期交付的三项改进

流量高峰下的读取提速

判断条目是否新鲜会给每次命中增加一次依赖调用。流量高峰时，标签存储的慢分片可能拖慢读取，即使缓存值已经就绪。Vercel 加入熔断机制，让读取临时用内存中的标签时间戳判断新鲜度，绕开慢分片。代价是回退期间可能短暂把刚失效的数据当作新鲜数据。该机制已在所有区域启用，据 Vercel 数据，最大区域在最高峰时 p99 读取延迟降至此前约五分之一，相关告警不再触发。

p99 延迟指将所有请求按耗时排序后，第 99 百分位对应的响应时间，即最慢的 1% 请求的耗时门槛。与平均延迟相比，p99 更能反映用户体验中的“长尾卡顿”：平均值被大量快速请求拉低，而少数慢请求往往决定用户是否感知到卡顿。文中说“p99 读取延迟降至此前约五分之一”，意味着高流量时段的尾部慢请求显著收敛。与之配套的熔断机制（circuit breaker）源自分布式系统实践：当某个依赖持续变慢或失败时，暂时切断对其调用、改用本地回退方案，避免请求排队拖垮整个链路，待依赖恢复后再放行。文中回退到内存中的标签时间戳，正是典型的降级路径，代价是短暂的一致性窗口。

更大存储、更少驱逐

Pro 项目在六月、Enterprise 项目在十月先后提高了存储预算。空间变大意味着因腾位置而驱逐缓存条目的情况减少。在驱逐频繁的 Enterprise 项目中，缓存未命中率约一天内减半。

缓存行为更可观测

Observability 的 Runtime Cache 视图新增部署标记、重新验证原因和写入利用率，帮助开发者把缓存行为变化与发布版本对照，看清条目为何被刷新，并识别那些写入后很少被读取的数据。

合并之后的变化

此前 Next.js 的 fetch 缓存和 unstable_cache 走 Data Cache，getCache 和 'use cache: remote' 走 Runtime Cache。合并后四个 API 统一由 Runtime Cache 承载，存储配额和使用工具归为一套，对使用编码代理的团队也更友好。

代码层面不变，账务层面有变。Pro 项目每个项目和环境获得独立存储配额，空间是 Data Cache 原团队共享池的 8 倍；Enterprise 项目获得此前 Data Cache 存储的 10 倍。原先不计费的 Data Cache 读写将按 Runtime Cache 定价计费，新团队自动使用 Runtime Cache，现有团队会提前收到迁移和账单细节。Vercel 建议迁移前检查缓存用量，按优化指南减少不必要的读写。

这次合并的信号很清晰：缓存正在从框架附属能力变成平台级基础设施。对多框架并存的团队，统一的配额和观测口径能减少心智负担；对成本敏感的团队，计费规则变化则需要提前算一笔账。