基于 Cloudflare 的双层缓存架构实践:CDN Cache 与 Worker Cache 的职责分离设计

在使用 Cloudflare Worker 构建全球加速、灰度发布、多源站调度系统时,缓存体系设计是决定系统稳定性与可控性的核心因素

很多工程师会同时使用:

  • Cloudflare CDN 自动缓存
  • Worker 内置的 caches.default 缓存

但如果没有明确区分两者职责,很容易出现:

页面版本混乱、发布失控、缓存击穿、数据不一致

本文将从工程实践角度,系统讲清:

  • CDN 缓存和 Worker 缓存的本质区别
  • 为什么 HTML 不应交给 CDN 缓存
  • 如何设计工业级双层缓存架构
  • 完整请求流程与版本更新逻辑(Mermaid 图)

一、缓存的本质分工

在 Cloudflare 边缘网络中,请求实际会经过两层潜在缓存系统:

复制代码
用户 → Cloudflare CDN Cache → Cloudflare Worker → Worker Cache → 源站

它们并不是同一层级,而是定位完全不同的系统组件


二、CDN Cache:自动化高速公共缓存

特点

  • 位于 Cloudflare PoP 边缘节点
  • 自动命中与回源
  • 延迟极低(毫秒级)
  • 几乎无计算成本

优势

✅ 极致性能

✅ 超大容量

✅ 自动分布式

局限

❌ 缓存 Key 不可精细控制

❌ 无法感知业务版本、灰度逻辑

❌ 不适合频繁更新内容

适用场景

👉 静态资源:

  • JS
  • CSS
  • 图片
  • 视频

通常配合:

http 复制代码
Cache-Control: public, max-age=31536000, immutable

实现一年级别缓存。


三、Worker Cache:可控的逻辑缓存层

Worker 内置缓存允许开发者自定义:

  • cacheKey
  • 版本参数
  • 地区维度
  • 灰度标识

特点

  • 完全由代码控制
  • 可嵌入业务逻辑
  • 可做版本隔离

优势

✅ 高度可控

✅ 支持发布系统

✅ 支持多版本共存

局限

❌ 相比 CDN 稍慢

❌ 消耗 Worker 计算资源

适用场景

👉 HTML 页面

👉 接口聚合结果

👉 动态内容


四、为什么 HTML 不应该交给 CDN 缓存?

在现代工程实践中,HTML 通常具备:

  • 版本更新频繁
  • 灰度发布需求
  • 多源站调度
  • A/B 测试

如果 HTML 被 CDN 缓存:

  • CDN 无法识别版本参数
  • Worker 逻辑被绕过
  • 发布行为不可控

最终会导致:

❗ 部分用户看到旧页面

❗ 部分用户看到新页面

❗ 灰度失效

这在工程上被称为:

缓存失控风险


五、推荐的工业级缓存职责模型

HTML

复制代码
Cache-Control: no-store

效果:

➡ CDN 不缓存

➡ 所有请求进入 Worker

➡ 由 Worker Cache 管控


静态资源

复制代码
Cache-Control: public, max-age=31536000, immutable

效果:

➡ 浏览器缓存

➡ CDN 长期缓存

➡ 零回源


六、完整请求流程(含版本控制)

命中
未命中
命中
未命中
用户请求
CDN Cache 是否命中?
直接返回缓存
进入 Cloudflare Worker
构造 cacheKey + 版本号
Worker Cache 是否命中?
返回 Worker 缓存
回源站获取内容
Worker 处理响应
写入 Worker Cache
返回给用户


七、版本更新时的自动刷新机制

通过引入构建版本号:

ts 复制代码
_v = BUILD_VERSION

缓存 Key 变为:

复制代码
/page?_v=20260203

更新后:

复制代码
/page?_v=20260204

效果

✔ 自动绕过旧缓存

✔ 强制回源

✔ 生成新缓存

无需:

❌ 手动 purge

❌ 等待过期


八、版本更新流程图

BUILD_VERSION 变更
旧版本缓存
缓存未命中
回源获取新内容
生成新缓存
提供新页面


九、最终架构总结

复制代码
                ┌──────────────┐
                │ CDN Cache    │  ← 静态资源
                └──────────────┘
                        ↓
用户请求 → Worker(逻辑调度) → Worker Cache(HTML/动态内容) → 源站

职责划分原则:

类型 使用缓存 目的
HTML Worker Cache 可控、可发布
API Worker Cache 动态聚合
JS/CSS/IMG CDN Cache 极致性能

十、一句话工程结论

CDN 管稳定资源

Worker 管动态逻辑

或者更直观一点:

CDN 缓存"死内容"

Worker 缓存"活页面"


结语

通过将 CDN Cache 与 Worker Cache 职责彻底拆分:

✅ 发布可控

✅ 性能极致

✅ 架构清晰

✅ 易扩展

将获得一套:

🌍 支持全球调度

🚀 支持秒级更新

🧠 支持复杂业务逻辑

的工业级边缘架构体系。

相关推荐
lizhongxuan13 小时前
AI 系统架构
架构
Drifter_yh15 小时前
【黑马点评】Redisson 分布式锁核心原理剖析
java·数据库·redis·分布式·spring·缓存
鸽鸽程序猿15 小时前
【Redis】zset 类型介绍
数据库·redis·缓存
予枫的编程笔记15 小时前
【Redis核心原理篇2】Redis 单线程模型:为什么单线程还能这么快?
数据库·redis·缓存
普通网友15 小时前
Android Jetpack 架构组件最佳实践之“网抑云”APP
android·架构·android jetpack
青春:一叶知秋19 小时前
【Redis存储】redis事务
数据库·redis·缓存
礼拜天没时间.20 小时前
JumpServer堡垒机部署与实战:从0到1搭建统一运维入口
linux·运维·架构·堡垒机·jumpserver·sre
智算菩萨1 天前
人工智能智能体研究综述:从理论架构到前沿应用
人工智能·机器学习·架构
古城小栈1 天前
后端视角:拆解春晚背后的高可用技术架构
后端·架构
羑悻的小杀马特1 天前
从虚拟化基石到云原生架构的降维打击:用dd/mkfs玩转namespace隔离,解锁Docker/K8S资源密码,看透物理机到云服务器的进化之路
docker·云原生·架构·namespace