CDN边缘缓存与内容预热：让用户第一次访问就命中
去年双11前，一个电商客户问我：“大促当天流量暴增，用户第一次访问商品页，CDN能直接命中吗？会不会全都回源把源站打崩？”
我问他：“预热做了吗？”
他说：“预热是什么？”
这是CDN使用中最容易被忽视的环节：CDN是被动缓存的，没人访问就不会缓存。大促当天第一次访问的流量，如果不提前预热，全都得回源。
01 什么是边缘缓存？
CDN边缘缓存，简单说就是把内容预先放到离用户最近的CDN节点上。
工作原理：用户请求到达CDN节点时，节点先检查本地有没有这份内容。有，直接返回（命中）；没有，回源拉取（未命中），再存一份以备下次。
两种缓存模式：
那家电商需要的正是主动缓存——大促前把热门商品图片、活动页面推到边缘节点，让用户第一次访问就命中。
02 为什么首次访问会慢？
CDN默认是被动缓存。一个文件在边缘节点被缓存之前，必须有人先访问它。
首次访问的路径：用户请求 → CDN节点 → 边缘节点没有缓存 → 回源站拉取 → 返回用户 → 存一份到边缘节点。
这个过程中，用户的实际等待时间包含CDN节点到源站的传输时间。如果源站在北京，用户在广州，即使CDN节点在广州，首次请求还是得从北京拉数据。
冷启动问题：新上线的活动页面、大促期间的新商品图片，CDN节点上还没有缓存。第一批用户访问时，所有请求都会穿过CDN直达源站，形成“回源风暴”。
那家电商大促前没预热，开售瞬间几万用户同时访问新商品页，CDN节点全无缓存，全部回源，源站瞬间被打满。
03 预热是怎么解决的？
预热就是把内容“主动推”到CDN边缘节点上，不等用户来触发。
操作方式：在CDN控制台选择要预热的URL列表（文件或目录），CDN系统自动把这些内容从源站拉取到各个边缘节点。
预热时机：
活动开始前1-2小时预热，给CDN系统充足时间分发
新版本上线前预热核心资源（首页、活动页、热门商品图）
重大更新时配合刷新使用：先刷新清除旧缓存，再预热新内容
注意：预热需要时间，文件越多、节点越多，预热时间越长。别等大促前5分钟才开始预热。
那家电商后来在大促前6小时预热了所有活动页和热门商品图片。开售时CDN节点直接命中，源站平稳度过高峰期。
04 预热与刷新的配合
预热和刷新经常被搞混，两者的使用场景完全不同。
刷新（Purge）：清除CDN节点上已有的旧缓存。用户下次访问时回源拉取最新内容。适合内容更新时用。内容更新后，先刷新旧缓存，再预热新内容，确保用户看到最新版本。
预热（Preheat）：主动把内容拉到CDN节点上缓存起来。适合内容还没上过CDN、大促活动、首次接入等场景。
顺序很重要：如果内容有更新，要先刷新再预热。先预热再刷新，等于把旧内容又推到节点上，白做了。
05 其他提升首次命中率的方法
合理设置缓存时间：静态资源（图片、CSS、JS）缓存时间设长一些，比如30天以上。频繁更新的资源可以根据业务调整。动态内容（API响应）不缓存或缓存时间极短。如果缓存规则在资源已缓存之后才修改，需要主动执行刷新操作让新规则生效。
开启忽略URL参数：URL带时间戳或随机参数，CDN会当成不同文件分别缓存，浪费缓存空间，降低命中率。忽略不影响内容的参数后，缓存效率明显提升。
写在最后
CDN边缘缓存的价值，在于让用户无论第几次访问，都能从最近的地方拿到内容。预热解决了“第一次访问”的问题，刷新解决了“内容更新”的问题，两者配合，才能让CDN真正发挥威力。
那家电商的运维负责人后来总结：“以前大促前只盯着服务器扩容，现在提前预热CDN，源站压力小了一大半。预热这件事，提前6小时做，比临时抱佛脚有用得多。”
你的大促活动预热了吗？今天就去控制台看看。
