91网避坑清单（高频踩雷版）：缓存管理一定要先处理

91网避坑清单（高频踩雷版）：缓存管理一定要先处理

前言 缓存看起来像个性能加分项，但做不好会把问题藏得更深：用户看到旧内容、接口返回不一致、上线频繁失败、运维成本飙升。把缓存管理放在开发与发布流程的首位，能在早期规避大多数高频踩雷。本清单聚焦实操，直接上手即可在项目里落地。

高频踩雷点速览

• 静态资源没有指纹（hash），却设置长缓存，导致用户拿不到最新资源。
• HTML/动态接口被 CDN 或浏览器缓存，结果用户看到旧页面或数据不同步。
• 缓存键过于粗糙（只按 URL），忽略 Query、Header、Cookie、Accept-Encoding 等差异。
• 多层缓存（浏览器→CDN→反向代理→应用内缓存→Redis）失效策略不一致，刷新无效。
• 缓存穿透/风暴：热点失效时大量并发请求穿透 DB/后端。
• 忽略缓存监控：命中率低、频繁驱逐、内存占满没告警。
• 在共享缓存中错误地缓存用户敏感数据（Cookie、Authorization）。

避坑清单（可直接落地的步骤） 1) 先画出缓存拓扑图

• 列出所有缓存层：浏览器、CDN（Edge）、反向代理（Nginx/Varni sh）、应用本地缓存、Redis/Memcached、DB 缓存层。
• 为每层标注：可控接口、默认缓存策略、失效方式（TTL、purge API、key 变更）。

2) 静态资源：文件指纹 + 长缓存策略

• 构建阶段对静态资源名称加哈希（app.abcdef.js）。上线时不再改名的文件可以设置超长过期。
• 推荐静态资源头： Cache-Control: public, max-age=31536000, immutable
• HTML 页面不要用长缓存；对入口 HTML 使用短 TTL 或 no-cache + ETag/Last-Modified。

3) 动态内容分级缓存策略

• 明确哪些接口可以缓存（公共数据、列表、非敏感数据），哪些不能（用户私有、支付、会话相关）。
• 对可缓存接口设计合理 TTL（例如列表 30s—5m、相对静态数据 1h—1d）。
• 对需要按用户/权限区分的内容，避免放入共享 CDN 缓存，或在缓存键中包含用户标识（但注意安全）。

4) 缓存键与 Vary 控制

• 在 CDN/反向代理层构建缓存键时包含必要维度：URL 路径 + query（或过滤关键 query）+ Accept-Encoding + 自定义 header（如 X-Region）。
• 使用 Vary header 来告知代理如何区分缓存（例如 Vary: Accept-Encoding）。
• 切忌把 Cookie 或 Authorization 直接当缓存键（会导致缓存命中率极低并可能泄露）。

5) 缓存失效与清理策略

• 对发布上线采用“指纹变更 + CDN 刷新”优先策略；尽量通过修改资源名避免大规模 purge。
• 提供自动化的 CDN purge API：部署脚本在发布后自动调用刷新接口。
• 对于必须 purge 的场景，支持按前缀清理和批量清理，并限制并发频率以免打击边缘层性能。

6) 防止缓存风暴（缓存击穿/穿透/雪崩）

• 热点 key 采用互斥锁（如 Redis SETNX）或 request coalescing，让第一个请求重建缓存，其余等待。
• 使用预热（warm-up）策略：在发布或缓存过期前主动更新热点缓存。
• 对短 TTL 的热门 key 考虑加上随机化过期（TTL ± 小比例）以打散大量同时到期。

7) Redis/Memcached 最佳实践

• 设置合理内存上限并选择合适的逐出策略（allkeys-lru 或 volatile-lru 取决于业务）。
• 对 key 做命名空间分组，避免单一大表导致扫描或全量删除困难。
• 限制单个 key 大小，避免超大 value 导致内存碎片化或慢操作。
• 打开 slowlog/监控 evictions 和 keyspace hits/misses。

8) 协商缓存与压缩

• 在能用 ETag 或 Last-Modified 的场景里优先使用协商缓存，减少带宽但保证内容新鲜。
• 确保边缘层与 origin 在压缩（gzip/brotli）策略上保持一致，避免出现同一 URL 返回不同实体导致命中率下降。

9) 安全与隐私

• 对用户私有页设置 Cache-Control: private, no-store 或确保不通过公共 CDN 缓存。
• 避免在缓存中保存敏感字段（token、身份证号），对日志脱敏。
• 清理机制要考虑法律合规（例如用户删除数据时需保证缓存也被清除）。

10) 可观测性与报警

• 收集并展示：缓存命中率、命中/未命中流量、backend 请求量、Redis evictions、热点 key topN、purge 次数与耗时。
• 设定阈值报警：命中率异常下降、eviction 激增、后端请求急增。
• 在关键链路加埋点，记录是否命中缓存用于问题回溯。

11) 测试与验证命中效果

• curl -I 或 curl -v 检查响应头（Cache-Control、ETag、Age、X-Cache 等）。
• 用流量回放或压测工具模拟真实流量序列，观察后端负载变化与命中率。
• 在预发环境演练 purge、回滚与缓存预热流程。

12) 自动化与 CI/CD 集成

• 将资源指纹、CDN invalidation、缓存预热等步骤写进发布流水线，避免人工遗漏。
• 把缓存配置作为代码（Infrastructure as Code）管理，合入版本控制。

优先级建议（落地路线图）

• 48 小时：做缓存拓扑图，检查静态资源是否指纹，快速改成哈希命名并设置长缓存；修正 HTML 的缓存头。
• 1—2 周：梳理可缓存接口与 TTL，部署必要的 Redis 监控，修复明显的缓存键问题。
• 1个月：实现 CDN purge 自动化、热点预热、缓存风暴保护逻辑并在 CI 中集成。
• 持续：完善监控告警、运行时分析 topN 热点、优化逐出策略与容量规划。

常用命令示例（用于快速排查）

• 查看 response header：curl -I https://your.domain/path
• 模拟无缓存请求：curl -H "Cache-Control: no-cache" -I https://your.domain/path
• 检查 CDN 返回头（可能包含 X-Cache 或 Age）：curl -I -H "Accept-Encoding: gzip" https://your.domain/resource

结语 缓存不是“加上就完事”的开关，而是一套需要设计、监控、维护的系统。把缓存管理放在优先级靠前的位置，能显著降低上线事故、提升用户体验并节省后端成本。按这份清单逐项梳理与落地，能把大多数高频踩雷提前发现并修正。需要我把这份清单转成发布流程中的检查表（可在 CI 中自动校验）吗？