电商大促前CDN回源预热核心是让源站缓存提前就位，需精准识别CDN回源流量、分层分级预热、严格限流控制，并建立量化验证闭环。
电商大促前对 CDN 回源做预热，核心目标是让源站缓存提前“就位”，避免开抢瞬间大量未缓存请求穿透到后端，引发雪崩。这不是简单地刷一遍 URL，而是结合业务节奏、缓存层级和回源特征的协同动作。
识别并隔离真实回源流量
预热的前提是准确区分 CDN 回源请求与普通用户直连——否则刷出来的可能是无效缓存，甚至干扰限流策略。必须在 http 块中定义可靠标识：
- 用
map匹配主流 CDN 的User-Agent（如AlibabaCloud-CDN、Tencent-Cache、Cloudflare），设$is_cdn_origin = 1 - 配合
set_real_ip_from和real_ip_header X-Forwarded-For，确保$remote_addr是 CDN 节点真实 IP，用于后续按 IP 预热或限流 - 禁用非 CDN 来源的预热请求：在预热专用 location 中加
deny all，再仅allow已知 CDN 的 IP 段
分阶段构建缓存层级
预热不是“全量刷”，要按资源热度和更新频率分级处理：
-
静态资源（图片/CSS/JS）：提前 48 小时开始，用脚本按 CDN 提供商推荐的回源 User-Agent 和 Header 发起 GET 请求；设置
Cache-Control: public, max-age=2592000，确保 CDN 和浏览器都长期缓存 -
商品详情页（HTML）：提前 6–12 小时启动，按商品 ID 列表轮询；缓存 key 必须含
$host+$request_uri+$args（但过滤掉 utm 类追踪参数），避免缓存碎片 -
动态片段（价格/库存）：不预热 HTML 全页，而是在 Nginx 层用 Lua 或
proxy_cache单独缓存 /api/price/{id} 这类接口，TTL 设为 10–30 秒，由边缘层拼装
控制预热节奏，防止反向压垮源站
预热本身是流量，必须受控，否则等于自己发起一次压测：
- 用独立限流 zone，例如：
limit_req_zone $remote_addr zone=warmup:10m rate=5r/s，仅对预热路径启用 - 预热请求加自定义 Header（如
X-Preload: true），在日志中单独标记，便于监控和快速熔断 - 配合
proxy_cache_lock on，防止同一资源被多个预热请求重复回源；搭配proxy_cache_lock_timeout 5s避免长锁阻塞 - 使用
proxy_cache_use_stale updating，确保预热更新期间旧缓存仍可服务，不出现空白期
验证与闭环反馈
预热效果不能只看日志，要建立可量化的验证机制：
- 在 server 块中开启缓存状态头：
add_header X-Cache-Status $upstream_cache_status，通过采样回源响应确认 HIT 率是否达标 - 配置专用监控 location，返回当前缓存命中率、预热请求数、最近 5 分钟回源失败数等指标，供运维实时查看
- 大促前 30 分钟自动触发一次“缓存健康检查”：随机抽 100 个高热商品 URL，用 CDN 节点 IP 模拟回源请求，统计 200 响应占比低于 95% 时告警
