Cloudflare Workers Cache 上线：双层缓存架构如何帮你省钱提速？

最近在折腾 Cloudflare Workers 的朋友们可能注意到了一个新的功能点：Workers Cache。这不仅仅是一个简单的缓存更新，它直接在边缘计算和用户请求之间加了一个“加速层”，对于追求极致响应速度或是想控制计算成本的同学来说，绝对是个值得细看的好东西。

为什么我们需要 Workers Cache？

以前我们用 Workers 的时候，每次请求过来，脚本都要跑一遍。哪怕你的业务逻辑只是去数据库拉点数据或者做简单的计算，只要请求量一上来，CPU 时间的消耗就跟坐火箭一样。虽然说 Workers 本身已经够快了，但在边缘节点上直接把结果缓存下来，岂不是连这点计算时间都省了？

这就好比你去便利店买可乐，以前是每次都得让店员现场调配（Worker 执行），现在则是直接从货架上拿已经调好装瓶的（缓存命中），效率自然不是一个量级的。

核心机制：双层缓存架构

这次的 Workers Cache 采用了下层 和 上层 两级缓存设计，这一招其实在很多 CDN 领域很常见，但应用在 Serverless 环境里效果尤为明显。

Cloudflare Workers Cache 的双层架构：下层边缘缓存响应极快，上层聚合缓存优化全球命中率。

1. 下层缓存：离用户最近

这就是位于 Cloudflare 全球边缘数据中心的缓存层。当用户发起请求时，系统会优先检查这里。如果数据存在，直接返回，根本不需要唤醒 Worker 去执行。这意味着响应延迟被压缩到了物理极限——也就是从边缘节点到你设备的网络时间。

2. 上层缓存：聚合全球请求

这是比较巧妙的一点。下层缓存虽然快，但因为分布在全球各地，单一节点的命中率可能会受限于当地用户的访问频率。上层缓存就像是一个中央大脑，它负责聚合全球各地的请求填充策略。

简单来说，当全球不同地区的用户请求相同资源时，上层缓存会协调这些数据的填充，确保更高的整体命中率。这样即使是冷门地区，也能通过上层的优化快速获取到热数据。

只有未命中时才烧柴火

整个工作流程的逻辑非常清晰，我们可以拆解一下两种情况：

• 命中缓存： 请求直接在边缘节点拦截，数据瞬间返回。此时 Worker 处于休眠状态，完全不消耗 CPU 时间。这对降低账单有着直接贡献。
• 未命中缓存： 请求穿透到 Worker，脚本开始执行。这一次执行会生成结果，系统会自动将这个结果同时填充到下层（边缘）和上层缓存中。等到下一个用户请求过来时，不管是本地还是异地，都有大概率直接命中缓存。

实际应用中的几点思考

既然这个功能这么好，我们在实际项目里该怎么用？

• 静态化生成的动态内容： 比如你的博客文章虽然是存数据库的，但更新不频繁。利用 Workers Cache，你可以在第一次访问时生成 HTML，之后几小时内所有用户看到的都是缓存的静态页，速度飞起且几乎零成本。
• API 聚合层： 如果你用 Workers 去聚合多个第三方 API 的数据，完全可以把聚合后的结果缓存起来。下游接口即使有点慢，你的用户端也感受不到，因为缓存返回是即时的。
• 成本控制： 对于受限于 CPU 执行时间的免费版或者低配版套餐，合理利用 Cache 可以让你在不氪金的情况下承载更多的并发流量。

总结

Cloudflare 这次的更新其实是在强调一个趋势：边缘计算不仅仅是计算，存储和缓存的本地化同样重要。 Workers Cache 这种“下层极速响应 + 上层智能调度”的组合拳，既解决了延迟痛点，又按住了成本狂奔的势头。

如果你还在苦于 Worker 的 CPU 时间超限或者响应速度偶尔抽风，不妨去看看文档，把这个缓存层用起来，说不定会有意外的惊喜。