一篇讲清楚一件事：蘑菇视频官网的缓存管理，你越早改越省事

一篇讲清楚一件事：蘑菇视频官网的缓存管理，你越早改越省事

开门见山：网站和视频都靠缓存提速、降成本，但缓存做得不好会带来用户看到旧内容、发布后修复困难、CDN费用飙升等麻烦。蘑菇视频官网越早把缓存体系理顺，后面线上变更、内容发布、流量暴增这些场景就越轻松。下面把具体策略和可直接上手的步骤讲清楚，照着做能省很多时间和钱。

一、先理解：有哪些缓存，作用是什么

• 浏览器缓存（用户端）：加快二次访问，节省带宽。由响应头决定（Cache-Control、ETag、Last-Modified）。
• CDN/边缘缓存：把文件放在离用户近的节点，减少回源。通过TTL、缓存键和缓存策略控制。
• 反向代理/应用缓存（如Nginx、Varnish）：减轻后端压力，可做更细粒度的缓存与缓存清理。
• 应用级缓存（内存、Redis）：加快动态数据响应，不直接用于静态视频文件但对接口性能影响大。
• Service Worker（离线/前端缓存）：可做离线体验和更复杂的更新策略。

二、给蘑菇视频官网分级策略（谁该长时间缓存、谁不能）

• 视频媒体文件（mp4、ts、chunk）：长期缓存+版本化文件名。示例：文件名含hash或时间戳，CDN TTL 长（例如 30 天 到 1 年）。
• HLS/DASH 清单（.m3u8、.mpd）：短 TTL 或采用版本化清单名。若采用动态直播流，边缘短 TTL 并支持分段缓存。
• 静态资源（js、css、图片、字体）：长期缓存 + 文件名内容哈希，Cache-Control: public, max-age=31536000, immutable。
• 页面 HTML（首页、帖子页等）：短 TTL 或 network-first 策略，使用 ETag/Last-Modified，或 Cache-Control: no-cache, must-revalidate，保证发布能及时生效。
• API 响应：按接口业务划分，关键数据短缓存（或无缓存），不频繁变更的数据可以使用短期缓存或stale-while-revalidate。

三、具体HTTP头示例（直接可用）

• 静态长期资源（含hash）： Cache-Control: public, max-age=31536000, immutable
• HTML 页面（需要及时更新）： Cache-Control: no-cache, must-revalidate 或 Cache-Control: public, max-age=60, stale-while-revalidate=30
• 视频切片（HLS ts）： Cache-Control: public, max-age=86400
• 支持条件请求： ETag: "abc123" Last-Modified: Wed, 21 Oct 2020 07:28:00 GMT

四、Nginx 常用配置片段（放在server或location）

• 长期静态 location ~* .(js|css|png|jpg|jpeg|gif|svg|ico|woff2?)$ { expires 365d; add_header Cache-Control "public, max-age=31536000, immutable"; }
• 页面 location / { add_header Cache-Control "no-cache, must-revalidate"; }

五、版本化与缓存清理策略（关键）

• 永远优先使用文件名版本化（content-hash）：发布新资源时不需要强制清CDN，只要引用新名字，老文件可自然过期或按需求清理。
• 对于必须同名更新的资源（如 HTML 模板、manifest），用自动化发布触发 CDN 清除 API 或采取短 TTL。
• 使用 CDN 的分区/标签/缓存键功能清理一组资源会更高效（CloudFront、Fastly、Akamai、腾讯云/阿里云均提供API）。

六、CDN缓存键与查询参数

• 明确缓存键规则：通常应以协议、域名、路径为主；对query参数做白名单（保留影响内容的参数，剔除跟踪参数）。
• 对含鉴权、用户相关的请求避免在边缘缓存，或使用Cookie/Authorization作为缓存键的前提下小心设置。

七、视频与流媒体的特别注意

• 使用分段（HLS/DASH）时，把段文件长期缓存，把清单短缓存或按照版本化策略更新。
• 开启 range 请求支持（Accept-Ranges）保证断点续传与 CDN 正确回源。
• 私有视频需用签名URL或Token，尽量在签名策略和TTL之间取平衡，避免短签名导致CDN缓存率差。

八、部署和发布流程建议（让未来更简单）

• CI 构建阶段生成带哈希的静态资源并把manifest写入页面模版。
• 发布时自动调用CDN的清理API清除必须即时失效的路径（可细粒度到manifest或首页）。
• 把缓存策略写进部署文档和代码库的配置，减少人为忘记或误操作。

九、监测与验证（上线后不要猜）

• 用 curl -I URL 检查响应头和CDN节点返回。
• 在CDN面板看 cache hit ratio、回源流量、分布统计。
• 用 Lighthouse/WebPageTest 评估首次与重复访问性能差别。
• 设置告警：回源流量异常、缓存命中率骤降、清理API失败等。

十、遇到问题如何快速回滚

• 如果某次发布导致用户看到错内容，优先： 1) 切回旧的HTML/配置（如果有蓝绿或回滚机制）。 2) 通过CDN清理受影响URL（若范围小优先清单式清理）。 3) 临时缩短相关资源的TTL并推送新的版本化资源。
• 改完再把流程补好：增加自动化清理或把资源改为版本化，避免重复修补。

结语：把缓存管理当成工程化的一部分，早期投入的标准化（文件名版本化、CI自动化、明确缓存策略）会在内容频繁更新和流量剧增时省下大量应急工时和成本。给蘑菇视频官网的实务路线：先做一次资产盘点并按上文分级，接着在构建/发布流程里加上版本化与CDN清理自动化，最后把监控和告警铺好——按这个顺序推进，越早开始越省事。

标签： 一篇 讲清楚 件事