关于91在线，我把缓存管理讲清楚后，很多问题都通了（越早知道越好）
关于91在线，我把缓存管理讲清楚后，很多问题都通了（越早知道越好）
最近在为91在线做缓存策略梳理时，发现很多看似复杂的问题其实都能用“把缓存管理讲清楚”来解决。把缓存链路、缓存规则和缓存失效机制彻底弄明白后，网站响应明显快了，后端压力降了，用户投诉、发布故障和流量突发的应急情况也少了。把自己的经验整理成这篇实操向文章，方便你在实际项目中快速落地。
一、先看常见症状，确认是不是缓存惹的祸
- 页面内容更新后用户看到的仍是旧页面
- 发布上线后样式/脚本没有更新，但访问不同地区/不同用户结果不一致
- 后端压力突然增大，Origin 请求激增
- 静态资源被设置了 Set-Cookie 导致 CDN 无法缓存
- API 返回被缓存，导致授权/用户隔离出问题 这些都提示需要从缓存策略入手排查。
二、缓存到底有哪些层级？弄清这些才能定位问题
- 浏览器缓存（HTTP Cache、Service Worker）
- CDN/边缘缓存（Cloudflare、Akamai、Fastly、阿里云 CDN 等）
- 反向代理/缓存服务器（Nginx、Varnish）
- 应用层缓存（Redis、Memcached）——用于会话、数据或页面片段
- 数据库缓存/索引缓存（更下游） 任何一层配置不当都可能导致问题，定位时按层级一步步排查。
三、基本概念与响应头实战（最常用的组合） 1) 静态资源（JS/CSS/图片）
- 目标：尽可能长时间缓存，减少重复请求
- 推荐响应头：Cache-Control: public, max-age=31536000, immutable
- 实战要点：使用带 hash 的文件名（例如 app.abc123.js），上线时不需要立即清 CDN 缓存 2) 版本化和 cache-busting
- 推荐方式：文件名版本（hash）优先，query string 方式次之（部分 CDN 对 query 不缓存） 3) HTML 页面（需要频繁更新或个性化）
- 推荐响应头（公共 HTML，可边缘缓存短时间）：Cache-Control: public, s-maxage=60, stale-while-revalidate=30
- 若页面含用户敏感信息或登录相关，使用：Cache-Control: private, max-age=0, no-store（或 s-maxage=0） 4) ETag 与 Last-Modified
- ETag 可用于精确变更检测，但在有多实例或 CDN 修改头时需统一生产 ETag
- 如果使用强缓存（hash 版本策略），就不必纠结 ETag 5) Vary 与 Cookie
- Vary: Accept-Encoding 必须有（gzip/brotli）
- 不要为静态资源设置 Set-Cookie，否则 CDN/中间缓存通常不会缓存该响应
四、典型配置示例（Nginx + CDN 场景）
- 静态文件（带 hash） add_header Cache-Control "public, max-age=31536000, immutable";
- HTML 页面（服务器渲染但可短缓存） add_header Cache-Control "public, s-maxage=60, stale-while-revalidate=30";
- API（有鉴权） add_header Cache-Control "private, max-age=0, no-cache, no-store, must-revalidate";
查看响应头（调试利器）：
- curl -I https://your.domain/path
- 在浏览器 DevTools Network 里看 Size、Status（304/200）、Response Headers、Request Headers
五、缓存失效（Invalidation）策略：发布、回滚、紧急修复的关键
- 最稳健：文件名带 hash（上线新版本生成新文件名），无需清 CDN
- CDN 支持的两种方式：
- 按文件逐条 purge（慢但精确）
- Tag/Prefix 清理（常用于批量）
- 发布流程建议：
- 先上传静态资源并确认 CDN 缓存可见
- 部署后端/HTML，确保引用到新 hash 的资源
- 紧急回滚：
- 如果必须立即撤回页面，使用 CDN 的 purge API 清掉对应 URL；如果 HTML 没有版本化，尽量提前预留短缓存窗口
六、提高命中率的技巧与常见坑
- 合理设定 TTL：短 TTL 导致 Origin 压力，过长 TTL 导致内容滞后
- 避免不必要的 Vary（Vary 会导致缓存碎片化）
- 不要在静态资源上染上 Cookie 或动态 header（浏览器会带 cookie，服务器不要 set-cookie）
- 对于移动/桌面差异内容，优先使用路径或子域来分流，避免使用 User-Agent 判断造成 Vary: User-Agent
- 使用 stale-while-revalidate/stale-if-error：降低用户延迟并提高可用性
- 监控缓存命中率（CDN/Proxy 的 hit ratio），不是 hit 越高越好，而是看是否命中了应该命中的资源
七、后端缓存（Redis/Memcached）实务
- 会话和短期数据：使用 Redis，设置合理 TTL（例如会话 30min-7day）
- 页面片段缓存：对不常变动但渲染成本高的片段缓存 60s-5min
- 缓存键设计：包含版本号、用户标识（如果是用户专属）或语言、设备信息（必要时）
- 缓存穿透/雪崩/击穿防护：使用空值缓存、互斥锁、请求排队或布隆过滤器
八、调试流程（定位缓存问题的快速流程） 1) 用 curl -I 检查响应头 2) 在 DevTools 网络面板关闭缓存后对比（Disable cache） 3) 临时绕过 CDN 访问 Origin（直接访问 origin server IP 或用 Host 替换） 4) 验证是否有 Set-Cookie 导致 CDN 未缓存 5) 在 CDN 控制台看日志：hit/miss/origin 请求数 6) 对出现差异的 URL 做全链路排查（browser → CDN → reverse proxy → app）
九、实际收益（把抽象落地后会看到）
- 页面首屏时间明显下降，用户感知更快
- Origin 请求数下降（节约带宽和后端资源）
- 发布回滚次数和线上事故减少
- 客服/用户投诉关于内容不一致、样式不更新的case 减少
十、快速核对清单（部署新版本前跑一遍）
- 静态资源是否使用 hash 命名？
- CDN 是否会缓存静态资源？有没有误设置 Set-Cookie？
- HTML 的 Cache-Control 是否和预期一致（是否需要边缘缓存）？
- API 是否设置了 private/no-store（如果与鉴权相关）？
- 有没有使用 Vary 导致缓存碎片化？
- 是否有 CDN purge 策略和权限？是否能快速回滚？
- 监控告警是否包含 origin 请求激增、cache miss 比例异常？
结语 把缓存管理弄清楚不是一次性的“开关”工作，而是从资源命名、响应头策略、CDN 配置、后端缓存设计到发布流程的系统工程。为91在线做这件事时，很多原本看着复杂的故障、瓶颈和发布痛点都被一条条清晰的规则和流程解决掉了。希望这篇实操指南能帮你在自己的项目上少踩坑、快见效。需要更针对你项目的诊断清单或 nginx/CDN/Redis 示例配置，我可以把具体的配置片段和排查脚本再整理一份给你。
