今天,我们将 Data Cache 并入 Runtime Cache,为开发者提供一个跨框架和 API 的数据缓存产品。如果你使用 Next.js 的 fetch 缓存或 unstable_cache,则无需更改代码。Pro 和 Enterprise 项目将获得更大的存储配额。
Runtime Cache 让你的代码在多个请求之间复用已获取或计算的数据,而无需运行单独的缓存服务。在过去一年中,我们提升了流量高峰期间的读取性能,增加了存储预算,并让缓存使用情况更易于调查。
我们为什么构建 Runtime Cache
Data Cache 最初是作为 Vercel 为 Next.js App Router 提供的数据缓存服务而推出的,被 fetch 缓存和 unstable_cache 使用。与存储完整 HTTP 响应的 CDN 缓存不同,Data Cache 存储你的应用程序用于生成这些响应的数据。例如,产品页面可以在为每个访客渲染个性化响应的同时,复用已缓存的目录数据。
我们希望开发者无需依赖 Next.js 就能使用该服务。去年,我们推出了 Runtime Cache,并提供了直接 API:来自 @vercel/functions 的 getCache。应用程序可以将其用于 Routing Middleware 中的功能标志查找、构建期间缓存 CMS 内容,以及 SvelteKit 和 Nuxt 应用中的数据缓存。
框架也可以通过自己的 API 暴露此服务。在 Vercel 上,Next.js 本身使用 Runtime Cache API 来实现 'use cache: remote',该功能缓存函数和组件的输出。
Runtime Cache 的工作原理
Runtime Cache 背后的基础设施是一个由许多团队共享的分布式缓存服务。一个 Go API 处理请求,并由每个 Vercel 区域的 Redis 集群提供支持。该服务每小时处理超过 4.4 亿次读取,并传输超过 18 TB 的数据。
每个区域都有自己的缓存。缓存命中需要一次往返,到达你的代码运行所在区域的缓存服务。Vercel 使用短期凭证处理身份验证,因此你无需管理 API 密钥。
在缓存未命中时,你的应用或框架会获取或计算值,并将其写入该区域的缓存。该服务不会检查其他区域是否有缓存副本。




应用从 Runtime Cache 复用产品数据,当缓存数据缺失或需要刷新时从源站获取。
每个缓存条目存储其标签和写入时间。当服务读取一个条目时,它会检查同一区域中单独的标签存储,以获取这些标签的失效时间戳。如果任何标签在条目写入后被失效,则该条目已过期。
例如,应用程序可以用 catalog 标记其所有缓存的产品数据。当目录发生变化时,使该标签失效会写入一个时间戳,即使有一百万个条目共享该标签。该服务无需逐个查找和删除这些条目。
失效操作会立即更新接收请求所在区域的标签存储。Vercel 的共享标签基础设施(也被 CDN 使用)通过全局推送管道分发时间戳,通常能在几百毫秒内到达其他区域。
你的应用或框架选择缓存什么并处理未命中。Runtime Cache 负责区域存储、身份验证以及跨区域分发标签失效。
我们已交付的功能
流量高峰期间更快的读取
检查条目是否仍然新鲜会给每次缓存命中增加一个依赖。在流量高峰期间,标签存储中一个缓慢的分片可能会延迟读取,即使缓存值已经可用。
我们添加了断路器,让读取可以暂时使用内存中缓存的标签时间戳来检查新鲜度,从而无需等待缓慢分片响应即可继续。在此回退期间,读取可能会短暂地将最近失效的数据视为新鲜。
我们在八月份在所有区域启用了断路器。在我们最大区域的最严重高峰期间,在可比流量下,p99 缓存服务读取延迟降至之前水平的约五分之一。针对此故障模式的待命警报已停止。
更多存储和更少驱逐
我们在六月提高了 Pro 项目的 Runtime Cache 存储预算,在十月提高了 Enterprise 项目的预算,为应用程序复用的数据提供了更多空间。这减少了为腾出空间存储新数据而驱逐缓存条目的需要。在频繁驱逐的 Enterprise 项目中,缓存未命中率在一天内大约减半。
更深入地了解缓存行为
我们在 Observability 的 Runtime Cache 视图中添加了部署标记、重新验证原因和写入利用率。这些功能可帮助你比较缓存行为与发布的变化、了解条目为何被刷新,并识别写入缓存但很少被读取的数据。
将 Data Cache 并入 Runtime Cache
我们通过整合到 Runtime Cache 来简化 Vercel 上的缓存。到目前为止,Next.js 的 fetch 缓存和 unstable_cache 一直使用 Data Cache,而 getCache 和 'use cache: remote' 使用 Runtime Cache。此次迁移将全部四个 API 纳入 Runtime Cache,因此你和编码代理可以使用一套存储预算和使用工具。
如果你使用 fetch 缓存或 unstable_cache,代码无需任何更改。在 Pro 上,每个项目和环境都有自己的存储分配,空间是 Data Cache 之前团队级池的 8 倍。Enterprise 项目获得之前 Data Cache 存储的 10 倍。
以前不计费的 Data Cache 读取和写入将遵循 Runtime Cache 定价。新团队自动使用 Runtime Cache,现有团队将提前收到迁移和计费详情。
有关推出、定价和提前选择加入的详细信息,请参阅 更新日志。迁移之前,请查看你的缓存使用情况,并遵循 优化指南 以减少不必要的读取和写入。
