我把51视频网站的缓存管理拆给你看：其实一点都不玄学（真的不夸张）
为什么要读这篇？ 因为视频网站的用户体验，很多时候不是靠更高清的码率堆出来的，而是靠“用户看到视频的那一瞬间”——播放能不能立刻开始、拖动卡不卡、并发高峰能不能稳住——这些都和缓存管理直接相关。今天把常见的缓存策略、实现细节和坑都拆给你看，按着做，体验提升明显，成本也能降下来。
一、先说清楚：缓存到底缓存什么？
- 静态资源：封面、播放器 JS/CSS、广告素材等，适合长期缓存。
- 媒体切片（HLS 的 .ts / fMP4 / DASH 的 segment）：以小文件为单位，可长期缓存但要区分清单和切片。
- 清单文件（m3u8、MPD）：短 TTL，频繁更新以反映直播/清晰度切换。
- 大文件（整片 MP4）：常用分片或支持 Range 请求，按需缓存。
- API 响应（鉴权、播放凭证、统计）：一般不能长期缓存，需做边缘缓存或微缓存策略。
二、常见架构与分层缓存（谁缓存、缓存在哪儿）
- 客户端缓存（浏览器/APP）：靠 Cache-Control、ETag 控制短期或长期缓存。
- CDN（边缘节点）：首选缓存层，降低回源压力并减少首字节延迟。
- 中间缓存/反向代理（Nginx、Varnish、OpenResty）：补充 CDN 功能，做缓存键定制、缓存规则、缓存预热、统计。
- 源站/对象存储（OSS、S3）：最终来源，尽量让回源少发生。
三、针对视频的缓存细节（最实用的部分）
- 区分清单与切片的 TTL：m3u8/MPD 保持短 TTL（几秒到几十秒），切片设较长 TTL（几小时到几天）。这样能保证清单及时更新而切片继续被缓存命中。
- 切片粒度要合适：2–10 秒常见。切片过短会增加请求数，过长影响快速切换和缓存命中。
- 用独立对象存储切片：每个切片一个对象，便于 CDN 缓存和并发分发。
- 带 Range 的大文件：很多播放器会请求字节范围（206 Partial Content）。CDN/中转层需支持缓存 Range 请求（部分 CDN 默认不缓存 206 响应，需要开启“缓存 Range”或把默认行为改为缓存完整对象）。最佳实践是把大文件切片化而非依赖 Range。
- Cache-Control 推荐实践：
- 切片：Cache-Control: public, max-age=86400（或更长，根据版权/更新频率）
- 清单：Cache-Control: no-cache, must-revalidate（或短 max-age）
- 静态资源：Cache-Control: public, max-age=31536000（配合版本号）
- 鉴权、签名 URL：用短时签名保护切片下载，CDN 在边缘验证或签名由客户端携带。签名短 TTL 时要小心会降低缓存命中率，常见做法是：签名只包含访问凭证部分（query string），并在 CDN 层做缓存键白名单或把鉴权放到边缘执行，而不是在源站处理。
- 缓存键规范化：决定哪些 query string 应计入缓存键。去掉无意义的追踪参数，保留影响内容的参数（清晰度、字幕、签名等）。
- 组合使用 ETag/Last-Modified：对于不想过度回源的对象，用条件请求减少数据传输。
四、缓存淘汰与热点管理（减少“回源雪崩”）
- 淘汰策略：LRU 是最常用，LFU+LRU 混合更适合冷热差异大的场景。
- 热点保护：对超热门内容做“放大缓存容量”或“多副本缓存”，避免短时间内大量回源。
- 缓存预热：对新上线或即将热播的内容在低峰期把切片预拉到边缘。
- 缓存失效策略：删除单个对象 vs 批量失效，使用分层标签（按节目/频道）对失效进行分组，减少误杀。
五、监控与指标（看清楚哪里出问题）
- 核心指标：缓存命中率、回源流量、边缘带宽占用、平均/95/99 百分位延迟、回源失败率。
- 采样日志：记录请求路径、缓存状态（HIT/MISS/EXPIRED）、响应码、带宽消耗，用于分析热点与异常。
- 自动告警：低命中率、短时间内回源峰值、回源错误激增，要触发告警并自动限制回源请求。
六、常见坑和避坑建议（实战经验）
- 坑：用短签名保护所有切片 → 导致命中率暴跌。 解法：把签名验证放到 CDN 边缘或只对敏感接口做签名。
- 坑：把清单和切片一视同仁，给清单长缓存 → 播放器拿到旧清单卡顿。 解法：清单短缓存，切片长缓存。
- 坑：依赖 206 缓存但 CDN 不支持缓存部分响应 → 导法：切片化或更换 CDN/开启专有功能。
- 坑：静态资源没有版本号，上线后用户看到旧文件。 解法：资源文件名加哈希或版本号。
七、工具与实现建议（落地清单）
- CDN：CloudFront、Akamai、Fastly、阿里云 CDN、腾讯云 CDN，根据成本和功能选支持 Range 缓存、边缘计算的服务。
- 反向代理：Nginx + Lua(OpenResty) 或 Varnish，用于自定义缓存键、鉴权下沉、缓存预热。
- 存储：对象存储（S3/OSS）存切片，源站只保留元数据/API。
- 观测：Prometheus + Grafana，或云厂商的监控，日志用 ELK/ClickHouse 做分析。
- 测试：用流量回放/压测工具（wrk、locust、siege）模拟高并发场景测缓存命中和回源压力。
结语：其实不玄学，只要把“分层缓存策略、切片与清单的不同生命周期、签名与缓存键”的问题想清楚，视频网站的延迟和回源成本能明显降低。把这篇当成一张清单：分层设计、区分清单/切片、合理 TTL、缓存键规范、热点保护、监控报警。照着执行，51视频网站级别的体验并不遥远。
