
缓存键(Cache Key)直接决定同一对象能否被复用,设计不当会导致大量的重复回源。常见问题包括把无关参数纳入键或对分片请求使用不同键。
首先要规范化 URL,移除会话 ID、跟踪参数等不影响内容的查询串,使用固定的主机与路径作为基础键。对 HLS/DASH 等分片流媒体,应把 manifest(索引) 与 segment(分段) 分别使用不同策略:manifest 可短 TTL、按用户/带宽分层缓存;segment 则使用统一键只按分段序号或时间戳。
例如:/video/12345/seg/0001.ts?v=1(应移除 ?v=1 除非代表内容变更)。可以改为 /video/12345/seg/0001.ts 作为缓存键。
在 CDN 配置或边缘逻辑中使用正则或自定义脚本处理缓存键,确保同一媒体的相同分段在不同客户端间命中。
分片大小和切片边界会显著影响缓存命中与回源频率。切片太短会造成大量小请求、增加回源压力;切片太长则影响播放启动与切换体验。
对于直播场景,通常 2-4 秒为宜;对于点播内容,4-10 秒可在启动速度与缓存利用之间取得平衡。关键是保证各码率分片彼此独立且对齐,便于不同码率间共享部分缓存(例如通过相同时间戳的分片键)。
若采用分段转换(transmuxing)或片段级别的逻辑,可以将编码后的部分静态资源(如相同 GOP 的中间帧)抽象为可复用块,从而提高不同码率间的缓存命中。
客户端应尽量在切换时请求与当前播放时间对齐的分片,避免跨片边界的回源请求;CDN 可启用对齐策略与范围请求支持,减少重复拉取。
合理设置 Cache-Control、ETag、Last-Modified、Expires 等头,可以让 CDN 边缘在本地决定是否回源。错误或过于保守的头会造成不必要回源。
对于分片资源建议设置较长的 max-age(例如 1 天或更多),并配合 immutable 标记对于不变分片避免频繁校验。对 manifest 使用短 TTL 和 stale-while-revalidate / stale-if-error 来平衡实时性与可用性。
当内容可能更新但多数时间不变时,启用 ETag 或 Last-Modified 允许边缘发送 If-None-Match 或 If-Modified-Since 到源站,源站返回 304 可大幅减小带宽与响应时间。
避免不必要的 Vary(如 Vary: Cookie)导致缓存分片化。仅在确实基于请求头差异返回不同内容时使用 Vary。
当边缘缓存未命中时,合理的回源策略能避免瞬时压力或雪崩式回源。常用做法包括 Origin Shield、回源分流与预热(warming)。
启用 Origin Shield(或中间缓存层)可将多个边缘节点的回源请求聚合到单个保护节点,从而减轻源站压力并提高命中率的一致性。
实现回源限流、排队与去重(request coalescing)可以避免短时间内大量边缘同时回源同一分片,减少源站并发负载。
对于热门视频或预期流量高峰,使用后台任务提前预热关键分片到边缘或 Origin Shield,可在开播/热播时显著降低回源。
只有量化指标才能驱动优化。核心指标包括边缘命中率、回源流量、回源请求数、回源响应码分布、回源延迟与成本。
监控应覆盖:edge hit ratio(边缘命中率)、origin offload(回源卸载比)、origin 304 比例、95/99 延迟,以及按路径/文件类型的细分数据。
通过灰度发布不同缓存键、TTL、切片长度策略做 A/B 测试,观察命中率变化与用户体验指标(startup time、rebuffer rate),以数据驱动调整。
结合自动化规则在命中率下降或回源激增时触发预热、调整 TTL 或切换回源策略,并对异常 5xx/4xx 回源率设置告警。