CDN 缓存命中率低时，预热适合用于已知的高热度资源发布场景，但不能替代基础的缓存配置优化。

快速处理思路与 API 示例

CDN 预热通常需要在云厂商控制台或调用 API 完成。对于频繁发布场景，建议直接使用 API 集成到发布流程中。以下是通用操作逻辑及 API 调用示例：

1. 控制台操作：登录 CDN 控制台，找到“预热刷新”或“缓存管理”模块，输入 URL 列表提交任务。

2. API 调用示例（curl）：大多数云厂商提供 OpenAPI，以下以通用 REST 风格为例（需替换为具体厂商 Endpoint 和签名）：

curl -X POST https://cdn.example.com/v2018-05-10/actions/PushObjectCache \
-H "Authorization: ACS3NvX..." \
-H "Content-Type: application/json" \
-d '{"ObjectPath": "https://your-domain.com/static/*.jpg", "SecurityToken": ""}'

3. 配额注意：多数厂商按每日 URL 条数或流量计算配额，提交前需确认剩余配额。

为什么会这样

缓存命中率低通常有两个原因：一是资源刚发布，边缘节点还没有用户访问过，缓存未建立；二是缓存配置不当，导致资源过早过期。

预热的作用是在用户访问前，主动让 CDN 边缘节点回源拉取资源并保存。这样当用户首次请求时，边缘节点直接返回缓存，减少回源请求。但预热不能解决动态内容或缓存规则配置错误导致的命中率低问题。

分步实操指南

第一步：检查缓存配置（关键）

在 CDN 控制台查看缓存过期时间（TTL）设置。缓存策略需根据资源类型区分：

• 带版本哈希的资源：如 app.v1.2.js 或 style.css?hash=abc，建议 TTL 设置 30 天以上，甚至永久缓存。
• 无版本资源：如首页 HTML 或未带哈希的图片，谨慎设置长 TTL，建议设置为分钟级或小时级，配合版本号更新。

风险提示：若静态资源未做版本管理却设置长 TTL，会导致用户无法获取最新资源（缓存污染）。

第二步：分析日志确定热点

不要盲目预热所有资源。通过 CDN 日志分析哪些 URL 访问量大。如果是新活动上线，提前整理好活动页面的核心资源 URL 列表。可使用以下命令分析本地 access.log：

awk '{print $7}' access.log | sort | uniq -c | sort -nr | head -n 10

提取出访问频率最高的前 10 个 URL 作为预热候选。

第三步：提交预热任务（自动化脚本）

对于大量 URL，手动提交效率低且易出错。建议使用 Python 脚本批量调用 API。以下是一个基于 requests 库的自动化预热脚本框架：

import requests
import json

API_URL = "https://cdn.example.com/v2018-05-10/actions/PushObjectCache"
HEADERS = {"Authorization": "YOUR_SIGNATURE", "Content-Type": "application/json"}

def preload_urls(url_list):
    # 多数厂商单次接口限制 1000 条，需分批提交
    batch_size = 1000
    for i in range(0, len(url_list), batch_size):
        batch = url_list[i:i + batch_size]
        payload = {"ObjectPath": "\n".join(batch)}
        response = requests.post(API_URL, headers=HEADERS, data=json.dumps(payload))
        if response.status_code == 200:
            print(f"Batch {i//batch_size} submitted successfully")
        else:
            print(f"Failed: {response.text}")

# 从文件读取 URL 列表
with open("hot_urls.txt", "r") as f:
    urls = [line.strip() for line in f if line.strip()]

preload_urls(urls)

第四步：监控回源带宽

预热期间回源带宽会暂时升高，这是正常现象。观察预热完成后，回源带宽是否下降，命中率是否回升。

怎么验证是否生效

1. 控制台指标

查看 CDN 控制台的“命中率”监控图表。预热完成后，命中率应有明显回升趋势。

2. 响应头检查

使用 curl 命令检查响应头：

curl -I https://your-domain.com/static/image.jpg

观察 X-Cache 或 Via 字段。如果显示 HIT 或包含 CDN 标识，说明命中缓存；如果显示 MISS，说明未命中。

3. 回源流量对比

对比预热前后的回源流量账单或监控数据。有效预热后，同等访问量下的回源流量应减少。

常见坑与风险

1. 预热动态内容

带有时间戳或随机参数的 URL（如 .php?t=123）通常不建议预热，因为每次内容可能不同，预热无效且浪费配额。

2. 忽视配额限制

大多数 CDN 服务商对预热任务有每日配额限制。不要一次性提交过多 URL，导致任务排队或失败。脚本中需实现分批逻辑。

3. 混淆刷新与预热

刷新会强制边缘节点回源更新，可能暂时降低命中率；预热是加载。如果在业务高峰期误操作刷新，可能导致瞬间回源压力激增。

4. 依赖预热解决配置问题

如果 TTL 设置只有 10 秒，预热再多也没用。必须先修正缓存规则，再考虑预热。尤其是无版本哈希的资源，切勿盲目设置长 TTL。