CDN缓存效率的评估不能只看响应时间或回源流量，命中率是最关键的指标之一。一个配置合理的CDN，静态资源命中率通常应稳定在90%以上，如果某些目录或接口的命中率明显偏低，通常说明请求URL在缓存键层面发生了不必要的分化。缓存键由CDN根据请求URL、Host、部分请求头生成，任何微小的差异都可能导致同一个资源被当成不同对象分别缓存，从而降低命中率。
要定位问题，需要先把URL拆开看。协议、域名、路径、查询参数、片段标识符各自对缓存键的影响并不相同。标准HTTP缓存中片段标识符不会发送到服务器，但路径和查询字符串会参与缓存键。多数CDN对查询参数顺序的处理并不完全一致，部分平台默认忽略顺序，而另一些平台对顺序敏感，这一差异会让同样的参数集合产生不同的缓存键。下面从影响命中率的核心因素开始分析。
一、命中率计算与缓存键构成
命中率通常用边缘节点命中数除以总请求数得出。总请求数等于命中数加未命中数，未命中会触发回源，因此命中率越低，源站压力越大，用户感知的延迟也越高。例如某个图片目录一天收到100万次请求，如果只有60万次命中，那么另外40万次都回源了，命中率就是60%。对于静态资源来说这个值明显偏低。
缓存键是决定命中的核心。CDN节点在收到请求后，会用缓存键去查找本地缓存。常见的缓存键包含协议、Host、路径、规范化后的查询字符串，有些CDN还会加入请求头、Cookie或自定义变量。如果不加约束，URL中的每一个字符变化都会体现在缓存键里，即便资源实体完全相同，也会被当作新缓存对象。因此分析命中率低下的URL模式，本质上是找出哪些URL片段在无意义地改变缓存键。
可以从访问日志入手做初步计算。下面这段Python代码模拟从CDN日志中统计命中率，日志文件里的MISS标记通常来自响应头或自定义字段。实际生产环境可以替换成自己的日志解析逻辑。
import re
from collections import Counter
def get_hit_rate(log_lines):
total = 0
miss = 0
for line in log_lines:
# 假设每行包含方法、URL、缓存状态，如 GET /a.jpg MISS
parts = line.split()
if len(parts) < 3:
continue
method, url, status = parts[0], parts[1], parts[2]
if method != 'GET':
continue
total += 1
if status == 'MISS':
miss += 1
if total == 0:
return 0.0
return round(1 - miss / total, 4)
logs = [
'GET /assets/logo.png HIT',
'GET /assets/logo.png MISS',
'GET /assets/banner.jpg HIT',
'GET /assets/banner.jpg HIT',
]
print(get_hit_rate(logs)) # 0.75
这段程序只处理简单日志，真实场景中日志字段更多，需要根据实际格式调整。重点不是计算本身，而是通过命中率反推哪些URL模式在制造大量MISS。统计时可以按路径分组，再观察每组内部查询参数的差异。
二、典型低命中率URL模式
低命中率URL通常有几个共同特征：查询参数里包含时间戳、随机数、签名或会话标识；同一个参数集合但顺序不同；路径大小写不统一；目录尾部斜杠有时有有时无；甚至URL中混入了用户ID、设备号等非资源维度信息。这些模式会让大量请求指向同一份内容，却形成成百上千个不同的缓存键。
时间戳和随机数是最常见的破坏因素。例如前端为了防止浏览器缓存，会拼上 _t=1717000000000 这样的参数，每次加载都可能变化。如果这个资源本身通过CDN缓存，时间戳变化会导致CDN不断回源。签名参数也存在类似问题，即使签名的计算结果每次都一样，但如果签名字符串中包含请求时间或随机盐，缓存键就会不断漂移。
参数顺序不一致同样值得警惕。比如 /api/list?page=1&size=20 和 /api/list?size=20&page=1 在业务上等价，但如果CDN没有对参数排序，就会生成两个缓存对象。更隐蔽的情况是大小写或尾斜杠差异，例如 /Images/Logo.png 和 /images/logo.png 在Linux文件系统上就是不同路径，但在业务上可能是同一个资源。识别这些模式可以使用归一化脚本，把URL中的数字、哈希串和长token统一替换成占位符，再聚合出现次数。
import re
def normalize_url(url):
# 将连续数字替换为{num}，32位十六进制串替换为{hash}
url = re.sub(r'\d+', '{num}', url)
url = re.sub(r'\b[a-f0-9]{32}\b', '{hash}', url)
# 将长度超过20的token串替换为{token}
url = re.sub(r'[A-Za-z0-9\-_]{20,}', '{token}', url)
return url
patterns = [
'/assets/logo.png?_t=1717000000000',
'/assets/logo.png?_t=1717000000001',
'/assets/logo.png?_t=1717000000002',
]
for p in patterns:
print(normalize_url(p))
# 输出:
# /assets/logo.png?_t={num}
# /assets/logo.png?_t={num}
# /assets/logo.png?_t={num}
从输出可以看到，不同时间戳被归为同一模式。后续可以在日志系统中按归一化后的URL聚合，找出那些模式相同但原始URL数量极大的请求组。如果某个资源路径下存在几十万种不同参数值，基本可以判定为缓存键设计问题。
三、通过URL规范化提升命中率
识别低命中URL模式之后，下一步是在源站或CDN边缘做规范化处理。规范化的目标不是改变业务功能，而是把不影响资源内容的差异消除在缓存键生成之前。具体手段包括：统一转为小写、去除默认端口、对查询参数排序、移除时间戳或无意义的随机参数、控制签名参数的生成方式等。
查询参数排序是最容易落地的一步。很多CDN提供查询参数排序选项，例如CloudFront、阿里云CDN、腾讯云CDN都有对应的缓存键配置。开启后，name=1&type=a 和 type=a&name=1 会被合并成一个缓存对象。但要注意，只有参数顺序不影响业务响应时才适合开启。如果后台确实依赖参数顺序，例如某些签名算法对原始字符串顺序敏感，就需要在源站先调整参数顺序，再生成签名。
对于时间戳和随机数，更推荐从源头上控制。静态资源的版本管理应该使用文件内容哈希或明确的版本号，而不是每次加载都生成新参数。比如将 app.js?_t=1717... 改为 app.js?v=3.2.1 或 app.ab12cd34.js。如果必须保留防缓存参数，可以在CDN侧配置忽略这些参数，使它们不参与缓存键。下面是一段Node.js示例，演示如何在请求到达CDN前重写URL，去除无用参数并排序。
function normalizeUrl(rawUrl) {
const parsed = new URL(rawUrl);
const ignored = new Set(['_t', 'timestamp', 'random', 'sid']);
const sortedKeys = Array.from(parsed.searchParams.keys())
.filter(key => !ignored.has(key))
.sort();
const query = sortedKeys
.map(key => {
const value = parsed.searchParams.get(key);
return `${key}=${value}`;
})
.join('&');
parsed.search = query;
parsed.pathname = parsed.pathname.toLowerCase();
return parsed.toString();
}
console.log(normalizeUrl('https://ipipp.com/Images/Logo.png?b=2&a=1&_t=1717'));
// 输出: https://ipipp.com/images/Logo.png?a=1&b=2
这段代码会把路径统一转为小写，忽略 _t、timestamp、random、sid 等参数，并对剩余参数排序。需要注意的是，实际业务中大小写不一定可以统一，例如部分后端接口区分大小写，因此只建议对确认为无状态静态资源的路径开启。
如果使用Nginx作为源站或边缘代理，可以通过自定义缓存键实现更细粒度的控制。下面配置片段使用变量拼接缓存键，忽略名为 ts 的参数，并对参数进行简单处理。生产环境建议配合Lua模块完成完整的参数解析与排序。
location / {
set $cache_uri $uri;
if ($args) {
set $cache_uri "$cache_uri?$args";
}
proxy_cache_key "$host$cache_uri";
proxy_cache_valid 200 1h;
add_header X-Cache-Status $upstream_cache_status;
}
上述配置还没有做参数忽略和排序，但它展示了缓存键可以由变量拼接而成。实际优化时，可以先在日志分析平台确认哪些参数对缓存键影响最大，再决定是否在CDN控制台配置忽略或归一化。对于签名参数，通常不能直接丢弃，因为业务需要校验完整性，此时可以把缓存键指向签名前的规范化URL，而不是包含签名的完整URL。
四、监控与持续治理
缓存命中率优化不是一次性工作。业务迭代会不断引入新的URL形态，如果缺乏监控，低命中率模式很快会再次出现。可以在CDN管理后台设置命中率告警，例如当某个域名或目录的5分钟命中率低于85%时触发通知。更推荐把日志接入实时分析平台，按归一化URL模式聚合，自动发现高MISS路径。
监控指标不应只看整体命中率，因为整体数据可能被大量高命中请求掩盖。比如首页HTML命中率很高，但某个API数据接口命中率极低，整体平均下来仍然不错。正确做法是按路径前缀、响应类型、缓存策略类型分别统计，尤其关注图片、JS、CSS、字体等静态资源目录。对于视频、软件包等大文件，命中率下降会造成大量带宽成本，更应单独监控。
还可以用简单的shell命令对日志做快速分析。下面的命令统计某个日志文件中缓存状态为MISS的URL出现次数，并输出前20个，适合在服务器上做临时排查。
awk '$NF == "MISS" {print $7}' /var/log/nginx/cdn_access.log | sort | uniq -c | sort -rn | head -20
其中 $7 表示URL字段，实际日志格式不同可能需要调整。持续治理的目标是把低命中URL的发现、规范化、验证、监控闭环起来。每次新增缓存规则后，可以回放历史日志验证命中率变化，确认优化效果后再全量上线。
最终，CDN缓存效率分析的核心是理解缓存键的生成逻辑，并围绕它去识别和消除URL中的无效差异。通过归一化查询参数、去除无意义时间戳、统一路径写法、监控异常模式，可以让更多请求直接命中边缘节点，降低回源带宽和源站负载，同时改善用户访问速度。