我把51视频网站的缓存管理拆给你看：其实一点都不玄学
开门见山——缓存不是神秘术，也不是单一开关可以解决所有延迟和成本问题。作为做过多个视频平台缓存改造的人，我把常见的误区、可落地的策略和排查技巧都拆开来讲一遍，哪怕你不是后台工程师也能看得懂、照着做。
先说结论（快速版）
- 视频分片（.ts/.m4s）尽量在CDN边缘做长缓存，配合签名 URL 控制权限。
- 播放器用短缓存或带 stale-while-revalidate 的清单（manifest）策略，确保切换清晰且能快速拿到更新。
- 静态资源（海报/缩略图/静态页面）走强缓存+指纹化；API 和鉴权接口走短缓存或不缓存。
- 缓存失效优先用版本化 URL，必要时再用批量清除接口（purge）。
缓存层次一眼看懂
- 浏览器缓存：受 Cache-Control、ETag、Vary 影响。用户侧最直接的体验层。
- CDN/边缘缓存：决定带宽成本和用户拉流延迟，通常对视频分片、图片和静态资源负责。
- 边缘/近源缓存（Nginx/Cache Server/Varnish）：当CDN未命中时的第一级回源。
- 源站/对象存储：最终存放，包括大文件（对象存储）和小元数据（数据库/缓存）。
常见误区
- “把所有东西都TTL=86400就完事” —— 会导致变更无法即时生效，私有内容泄露风险也提高。
- “频繁 purge 就行” —— purge 成本高、容易影响缓存命中率。用版本化更稳。
- “CDN 自己会把一切做好” —— CDN 只是工具，缓存策略和 cache keys 的设计才决定效果。
实操：如何配置不同资源的缓存策略（推荐值）
- 视频分片（chunk/.m4s/.ts）
- Cache-Control: public, max-age=86400*7（7天或更长）
- 使用签名 URL 或短期 token 控制权限（保留长 TTL 的同时保护内容）
- 清单（M3U8/MPD）
- Cache-Control: public, max-age=5-60, stale-while-revalidate=30
- 目的：允许边缘在短 TTL 过期后继续响应同时后台异步刷新，用户不卡顿
- 静态页面/图片（海报、缩略图）
- Cache-Control: public, max-age=86400*30（指纹化后）
- 对不指纹化的资源设置合理短 TTL，并准备好 purge 或版本化策略
- API/鉴权/计数类接口
- Cache-Control: no-store 或 private, max-age=0
- 对于可缓存的计数/排行榜类数据，采用应用层缓存（Redis）并用异步批量刷新
探针工具和排查方法
- 看头信息：curl -I https://your.cdn/xxx.ts
- 关注：Cache-Control、Age、X-Cache（或 CDN 自定义的命中头）、ETag、Last-Modified
- 用户端复现：模拟低带宽、不同地区，观察首包时间（TTFB）和缓冲率
- 指标监控：
- 边缘命中率（Edge Hit Ratio）
- 回源流量 / 边缘流量比
- 首字节时间（TTFB）和启动播放时间
- 缓冲率（rebuffering）
- 针对回源暴增：开启 rate-limit、设置源站缓存（short-lived），并采用自动扩容或流量削峰机制
缓存键（Cache Key）设计要点
- 精简：常用按 host + path + normalized query，避免把用户 Cookie 或 Authorization 直接当成缓存键
- 针对分片：把 query 中的时间戳等动态参数剥离或规范化
- 对于多变的 Accept-Encoding 或语言内容，使用 Vary 头控制
处理变更和失效的实用套路
- 版本化 URL（最稳）：静态资源/分片在部署时带版本号，用户请求自动命中新版本。
- 局部 purge：当必须即时下线单个资源，调用 CDN 提供的 purge API。注意批量 purge 会影响命中率。
- Stale strategies（过期但可用）：stale-while-revalidate 和 stale-if-error 在网络波动时非常好用。
私有视频的缓存与鉴权
- 使用签名 URL（短期有效）或边缘鉴权（Edge Auth）把鉴权放到 CDN 层，避免每次都回源鉴权。
- 对于短视频或付费试看片段，可把播放清单短 TTL + 分片长 TTL 结合，确保付费内容不会长期驻留在边缘。
成本和性能的权衡
- 延长边缘 TTL 会降低回源带宽，但可能增加缓存存储成本与一致性问题。
- 更高的命中率不一定等于用户体验更好：低延迟的短 TTL 配合高命中率的智能预热可能比单纯延长 TTL 更合适。
- 建议做 A/B 测试：不同地区、不同设备分组试验缓存策略，量化影响。
部署/上线的安全操作流程
- 先在小流量环境（灰度）验证新策略，观察命中率和用户端指标。
- 对重要资源优先采用版本化，上线后逐步缩短旧版本保留时间并最终 purge。
- 自动化脚本化 purge 操作并加权限控制，避免误操作带来全量回源。
常见坑和实际解决办法
- 坑：CDN 返回 200 但 Age=0（表面命中，实为回源）—— 排查 CDN 的缓存键是否包含了动态头或 Cookie。
- 坑：使用 ETag 却被浏览器忽略—— 检查是否有 intermediate proxy 修改了响应。
- 坑：短 TTL + 大量 purge —— 换成微短 TTL + stale-while-revalidate 或版本化。
最后一句话 缓存管理看起来复杂，是因为它牵涉到性能、成本和一致性的多个维度。把系统拆成“哪些是可以长期缓存”“哪些需要短期刷新”“哪些靠鉴权控制”，然后用证据（日志、指标）来驱动调整，就能把“玄学”变成可复现的工程实践。需要我把你现有的缓存头、CDN 命中率和回源流量看一眼，我可以给出更具体的改进清单。
