绕开CDN和边缘缓存这两个词很多团队其实是在裸奔跑业务。不少人以为接了CDN就万事大吉结果回源率居高不下、动态接口慢成狗、资源被盗刷最后排查一圈发现全是缓存策略没做对。我这些年经手过的项目里真正把静态、动态、签名鉴权三套组合拳打完的团队少之又少。多数情况是静态资源全量缓存但不设版本管理动态请求一点不缓存全靠回源硬扛鉴权要么没有要么全站强制导致CDN形同虚设。这篇就把我这几年调CDN和边缘缓存的经验全部摊开来讲从设计思路到实操步骤从参数计算到踩坑记录一次说透。1. 整体架构与缓存策略的设计思路1.1 先想清楚三件事再动手拿到一个项目要配CDN不要急着去控制台点按钮。我先问三个问题静态资源占多大比例动态接口的实时性要求到底有多高业务有没有被刷量和盗用的风险这三个问题的答案基本决定了整套策略的骨架。我之前碰到过一个电商项目前端静态资源占了全部流量的60%以上但动态接口的查询频次极高而且商品价格接口对实时性要求非常苛刻。如果一刀切全站缓存价格就乱了如果全站不缓存源站机器再多也扛不住。最终落地方案是静态资源全量缓存加版本号管理动态接口按业务类型分级处理——强实时的不缓存弱实时的做几秒到几十秒的短缓存被刷风险高的接口统一加签名鉴权。这里面的核心逻辑是分层。你可以把CDN理解成一个多级的仓库体系边缘节点是离用户最近的便利店中间层是区域仓库源站是总仓。静态资源是可以放心堆在便利店的标品动态数据则要分清楚哪些是易腐品必须现做现卖哪些是保质期长的可以预先封装。想清楚这个类比再去做缓存策略就不会拍脑袋了。1.2 缓存策略的决策模型我习惯用一个简化模型来判断一个请求能不能缓存先看URL是否带查询参数再看响应头里有没有Cache-Control和Vary最后判断请求是否携带了影响响应内容的Header或Cookie。这个模型看起来简单但实际落地时坑非常多。比如很多团队会忽略Vary头的存在导致同一个URL缓存了多种不同版本的响应内容CDN节点不知道该返回哪一份。又比如有的动态接口其实数据变化不频繁但URL里带了一个时间戳参数导致缓存永远命中不了。这些都是我在真实项目中踩过的坑后面会展开讲。2. 静态内容的缓存策略详解2.1 缓存键与版本管理的黄金搭档静态资源缓存最怕的一件事就是文件名不变但内容变了用户还在看旧版本。最常见的问题部署新版本后入口HTML引用的还是带缓存指纹的旧文件但CDN节点上旧文件已经过期被清除用户拿到的页面就出现了资源加载失败或新旧混杂。解决这个问题的标准做法是文件名指纹 长缓存。也就是Webpack或Vite这类构建工具在打包时给每个静态文件生成基于内容哈希的文件名CDN对这些文件名设置超长时间的缓存同时入口HTML不缓存或只缓存极短时间。这样每次发布后入口文件都会拿到最新内容引用的也是带新指纹的资源CDN节点上不管有没有老文件缓存都不会影响新版本的正确加载。实操上我建议的配置是这样的资源类型Cache-ControlCDN缓存时间HTML入口文件no-cache 或 max-age0不缓存或120秒JS/CSS带哈希文件名public, max-age31536000, immutable一年图片/font/媒体文件public, max-age31536000一年SVG/图标小文件public, max-age604800七天这里有个关键点Cache-Control里如果带了immutable字段CDN和浏览器都会认为这个资源永远不会变连重新验证都不会发。这个字段只适合带内容哈希的文件名绝对不能用在接口上。2.2 缓存键设计的细节很多CDN默认的缓存键就是完整URL这会导致一个很典型的业务问题同一个资源PC端和移动端需要不同的尺寸或不同的裁剪参数如果两个端共用同一个URLCDN只会缓存第一份响应第二个端拿到的就是错的内容。解决方法是分场景定制缓存键。拿阿里云CDN和腾讯云EdgeOne来说控制台里都有缓存键配置功能可以指定忽略或保留某些参数。我的习惯做法是把影响响应内容的关键参数比如模板ID、客户端类型、分辨率标识放进缓存键保留范围把那些统计类、时间戳类、随机数类参数比如utm_source、_t、callback全部忽略掉。还有个容易踩的坑是大小写问题。默认情况下大部分CDN对URL是大小写敏感的但源站如果是大小写不敏感的应用同样的资源可能被缓存成两份白白浪费空间和回源带宽。建议在CDN配置里打开URL大小写归一化功能或者确保应用层做好重定向统一。3. 动态内容的缓存策略实操3.1 动态内容真的能不回源吗先说结论动态内容不仅能做边缘缓存而且是降本增效最明显的一块。关键是搞清楚哪些能缓存、缓存多久、怎么保证一致性。我看过一个社区论坛的架构帖子列表接口的QPS常年维持在几千但数据其实每分钟才更新一次。这个接口回源率原来几乎100%源站MySQL压力非常大。后来做边缘缓存优化把TTL从0调到30秒回源率直接降到不足5%源站Load Average从5以上降到1以下响应时间从平均200毫秒降到20毫秒以内。动态接口的缓存分级策略我建议按下面的框架执行完全不缓存登录态相关、购物车、下单、支付回调、实时价格、库存查询秒级缓存5-30秒首页推荐流、排行榜、公告类接口分钟级缓存60-300秒文章详情、评论列表、热门话题榜边缘计算参与对动态内容做个性化拼接比如用户昵称、头像等由边缘脚本注入这个分级的前提是你要对业务容忍度有清晰的认知。之前有个项目做资讯类App资讯详情页的阅读量要实时显示做了5秒缓存后发现阅读量表现明显卡顿。后来改为文章详情内容缓存5分钟阅读量字段单独走后端接口不缓存两边异步合并问题就解决了。代价是架构复杂了一些但用户体验完全不受影响。3.2 Cookie、Header与Vary的复杂场景动态内容缓存最头疼的不是TTL设置而是Vary头和Cookie造成的缓存污染。最常见的反面案例某个页面针对不同用户显示不同的促销信息开发者把用户身份放在Cookie里。如果CDN不知道这个逻辑直接缓存了第一个用户的页面后面所有用户拿到的都是同一个人的促销信息。解决办法有两个思路一是在关键路径上的接口返回Vary: Cookie当然这会导致缓存碎片化严重缓存命中率直线下降二是在边缘节点上用规则判断——如果请求带了某些关键Cookie就直接回源不缓存这样既避免了污染又保障了未登录用户的缓存命中。另一个容易被忽视的Header是Accept-Encoding。如果你的源站开启了Gzip或Brotli压缩同时CDN也做压缩需要在缓存键里区分到压缩格式否则同一个URL下有的用户拿到gzip版本、有的拿到br版本网络传输效率会受到影响。大部分商业CDN现在都能自动处理这个字段但自建边缘缓存时就要特别留意。关于Vary头的处理我一直强调一个原则少用Vary兜底多用缓存键显式区分。显式区分意味着你能预测到哪些维度会导致内容变化提前在缓存键配置里列出来。Vary是响应侧的被动声明用多了会直接打碎缓存。曾见过一个项目把Vary: Accept、Vary: Accept-Encoding、Vary: Cookie全都返回上缓存命中率直接跌到个位数。4. 签名鉴权方案的实现与关键要点4.1 为什么边缘鉴权必须与缓存配合很多团队的鉴权方案只在源站做CDN边缘节点不校验这就给了刷量盗用很大的可乘之机。攻击者可以直接绕过CDN回源或者拿到带签名的URL后重复刷取。边缘鉴权的意义在于把校验从源站前置到离用户最近的地方无效请求根本到不了源站。但边缘鉴权有个天然的矛盾点签名参数通常是加在URL query里的如果缓存键把整个query都纳入就完全无法命中缓存每个请求都要回源鉴权就形同虚设了。解决办法是双轨制鉴权相关参数不参与缓存键计算业务参数单独提取。CDN厂商在处理上面的做法一般是把timestamp、sign、token这类参数标记为鉴权参数在缓存键里自动剔除。4.2 时间戳与MD5签名的原理与计算流程最常用的边缘鉴权方式是时间戳签名也叫URL防盗链。核心流程是请求方用约定好的Key对URL路径和过期时间计算签名CDN节点校验签名合法性以及时间戳是否过期。具体签名串的拼接规则不同厂商略有区别但思路是一致的。以常见的经验为例将URI路径、客户端IP可选、过期时间戳拼成一个字符串加上私钥做MD5或HMAC-SHA256计算最终签名的URL形如 /video/10001.mp4?auth_key1699999999-0-0-xxxxxmd5hashxxxxx。我建议优先使用HMAC而非裸MD5拼接前者能有效避免长度扩展攻击虽然防盗链场景并发没那么高但安全性的成本几乎为零何乐而不为。实际计算时要注意拼接顺序必须严格按照约定前后顺序错了哪怕Key对也会校验失败。4.3 多重组合时间戳校验、路径限制与Referer白名单成熟的边缘鉴权方案通常是组合拳。只用Referer黑名单很容易被伪造只用时间戳密钥一旦泄露全部玩完。我常用的组合是Referer限制做第一道拦截 时间戳签名做第二道门槛 单链接访问频次限制做兜底。针对下载类和视频类资源我还特别留意了单链接限频和客户端IP维度限频。单链接限频的意义在于即使签名被合法用户分享出去攻击者拿到链接以后也只能有限使用不会瞬间刷爆源站。实践中我遇到过签名URL被爬到公开平台导致CDN流量费用暴涨十几倍的案例最后就是靠限频规则把损失控制住了。4.4 鉴权配置的回源透传与容错最后一个内部要点鉴权通过后请求回源时签名参数要如何处理。有的CDN默认会把整个原始URL透传给源站这有两个问题一是源站如果也做鉴权需要再做一次校验二是签名参数会污染源站日志和缓存键。我一般建议CDN在鉴权通过后把签名参数剥离掉再回源源站看到的是干净的路径。容错设计也不能少。CDN鉴权失败时返回403还是302重定向要按业务场景来定。资源类我建议直接返回403页面类建议重定向到一个统一的提示页。千万不要在鉴权失败时返回200和一个错误JSON这样容易被误判为成功请求。5. 工具选型解析与配置实践5.1 主流CDN方案的差异与适用场景现在市面上CDN产品五花八门我自己的判断依据就三条对动态内容的支持程度、缓存键的灵活度、边缘脚本能力。传统CDN如阿里云CDN、网宿在静态资源分发上非常成熟覆盖节点多、稳定性好但对动态内容的处理要靠大量规则堆叠灵活性一般。云原生边缘平台如Cloudflare Workers、腾讯云EdgeOne、又拍云边缘计算则在动态内容、边缘逻辑、个性化处理上明显更强适合需要精细控制缓存的业务。自建Nginx/Varnish做边缘缓存则适合预算敏感、技术掌控力强的团队但运维成本和风险都更高。方案静态分发动态加速缓存键细粒度边缘脚本上手成本传统CDN很强一般中等弱低云原生边缘平台强强高强中自建Nginx中等手动控制极高无高5.2 一套可以直接抄作业的Nginx边缘缓存配置自建边缘缓存最考验功底我直接给出一份经过验证的Nginx配置模板覆盖了静态缓存、动态短缓存和基本鉴权校验。# 静态资源长缓存 location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2?)$ { expires 365d; add_header Cache-Control public, immutable; # 命中缓存直接返回不进源站 try_files $uri 404; } # 动态API短缓存 location /api/ { proxy_cache my_cache; proxy_cache_key $uri$args; proxy_cache_valid 200 30s; proxy_pass http://backend; } # 简单鉴权校验校验失败直接返回403 location /protected/ { if ($arg_sign ) { return 403; } # 实际项目中应该验证时戳 签名写法略 proxy_pass http://backend; }这份配置能解决60%的场景问题但真正生产环境还需要增加缓存锁、优雅降级、异常状态码处理等。下面用章节5.3单独讲。5.3 生产级缓存回源与降级配置生产环境里Nginx缓存最怕的是缓存雪崩和惊群效应。缓存雪崩是指大批缓存同时过期请求全部打到源站惊群效应是同一个热点key同时过期后成千上万个请求同时触发回源。对应的处理手段叫缓存锁或回源锁。原理是当缓存未命中时只有一个请求去源站拉取数据并回填缓存其他请求排队等待或直接拿旧缓存兜底。OpenResty里可以用lua-resty-lock实现Nginx商业版有专门的指令社区版可以借助共享字典自己实现。具体的措施我通常会组合使用缓存过期抖动在TTL基础上加一个随机偏移避免集中过期stale-if-error允许返回过期的缓存内容即使源站挂了也能保证服务不停请求合并同一瞬间未命中的请求共享同一个回源任务特别是允许过期缓存兜底这条真的建议所有自建边缘缓存的团队都打开。我见过一个案例源站数据库宕机4个小时靠这一条规则前端用户几乎完全无感只是看到的数据旧了几个小时对很多阅读类业务来说完全能接受。6. 常见问题与排查技巧实录6.1 热门问题的排查思路速查长期和CDN排查打交道我整理了一张问题速查表不管是自建还是商用排查思路都是通用的现象可能原因排查方向更新内容用户看不到缓存未刷新/忽略版本号检查缓存键和刷新API回源率居高不下缓存时间过短、URL参数过多优化缓存键加CDN层缓存动态接口时好时坏缓存污染或TTL不一致检查Vary、Header、Cookie静态资源访问403鉴权参数被缓存键吞掉检查鉴权配置与缓存键匹配带宽暴涨线路拥塞被刷量导致立即加限频和签名鉴权部分用户拿到乱码压缩格式未区分检查Accept-Encoding处理逻辑6.2 我在实际项目中踩过的坑与排查过程讲一个真实的排障案例。有一次一个客户的动态接口在CDN切换后部分用户频繁反馈数据错乱。第一反应是回源出了问题但查了源站日志发现回源请求都是正常的。后来抓包发现问题出在CDN节点缓存了用户A的数据然后用户B带着不同的Cookie访问时CDN依旧返回了缓存的那份。当时客户端请求的是同一个URL但响应内容依赖Cookie里的城市ID。排查过程是先看响应头发现没有Vary: Cookie再看CDN缓存键没有把Cookie维度纳入最终调整策略——CDN规则里判断请求带了city_id这个Cookie就回源不带就缓存。这个问题前后花了快半天才定位不是技术有多难而是容易被同一个URL这个表象迷惑。另一个印象深刻的坑是大小写敏感。某项目的静态资源在源站是大小写不敏感存储的但浏览器请求里同一张图有时全小写、有时首字母大写。CDN把这两种URL当成了两份缓存一个月的时间里莫名其妙多出30%的流量费用。后来在全站的一次CDN配置审计中才发现这30%的流量全部来自重复缓存和重复回源。开启了路径大小写归一化后流量立刻恢复正常。6.3 边缘缓存健康度的主动观测技巧除了被动排查我更推荐日常就建立一套缓存健康度观测指标。核心指标就三个回源率、缓存命中率、平均首字节时间。回源率是最直观的指标。一个优化良好的静态资源站点回源率应该在5%以下动态内容经过分级处理后整体回源率控制在20%以内是常见的健康状态。缓存命中率则是另一个角度看同一件事它体现的是CDN内部存储的价值。三者的关系我用一个简单的公式来理解用户平均响应时间约等于命中率乘以边缘响应时间加上回源率乘以回源响应时间。在边缘响应时间基本恒定的前提下回源率每降低10个百分点平均响应时间的改善是非常可观的。日常观测建议小时粒度去盯这三个指标的曲线一旦发现回源率在半小时内快速爬升大概率是缓存时间配置被改了或者是某个热点资源大量过期。热点的处理办法我特别推荐主动预热在流量高峰来临前把即将上线的爆款资源通过CDN厂商的预热接口提前推送到主要边缘节点。电商大促前、游戏开服前这招屡试不爽能极大降低回源压力。7. 组合拳的落地建议从我自己的经验看CDN和边缘缓存的优化从来不是一个配置就能搞定的而是一套方法论和工具链的组合。静态资源靠指纹版本和长缓存来降本动态内容靠分级短缓存和边缘能力来提效鉴权则靠时间戳、路径限制和频次限流来构筑边界三者环环相扣。真正做得好的团队都有一个特点把缓存当成一个日常运维和持续迭代的子系统来对待而不是上线时配置一次就再也不管。缓存策略是需要跟着业务形态演进的营销活动来了要开短时强缓存新功能上线了要临时绕过缓存验证恶意刷量来了要立刻收紧鉴权和限频。这些动作如果全靠手动去控制台上敲一定跟不上节奏。我个人的习惯是所有CDN配置都会用基础设施即代码的方式管理起来比如Terraform配合各云厂商的Provider或者至少保存一套完整的命令行调用脚本。这样任何线上变更都有迹可循、可回滚也方便在不同环境间复制同样的策略组合。核心的一点心得也是一个很多人不太适应的心态转变做缓存优化追求的不是所有请求都命中缓存而是源站的每个请求都是必要的。这句话我琢磨了很久包含的意义远超字面必要回源要尽力保障不必要的回源要尽力消灭该牺牲的缓存一致性就去牺牲该保留的实时性就坚决保留。理解了这一点前面讲的所有策略、参数、配置就都变成了一盘能真正下好的棋。