缓存策略
决定缓存什么、在哪、如何失效——决定缓存帮忙还是添乱的三问。
为什么
从不命中的缓存浪费内存；过时缓存供错数据；失效太激进只是慢网络调用。缓存策略是把数据放对层（浏览器、CDN、应用、DB）配对 TTL 和对失效触发。做好降 DB 负载 80%、延迟 10 倍；做差造出几乎不可复现的过时数据 bug（依赖时序）。策略须按数据类型显式——单一全局 TTL 是没人想过的标志。
何时使用
当读路径慢或 DB 过载。半天设计。命中率降或过时 bug 出现时重访。
如何做
1. 每数据类型分类：静态（少变）、近静态（分钟变）、动态（常变） 2. 静态（配置、商品目录）→ CDN + 长 TTL（1 时-1 天），写时失效 3. 近静态（用户资料）→ 应用缓存（Redis）+ TTL（1-5 分）+ 写透 4. 动态（实时库存）→ 不缓存，或极短 TTL（5 秒）配 stale-while-revalidate 5. 选失效：TTL（简单、最终一致）vs 显式（复杂、始终新） - 默认 TTL；仅当过时致害（如价格）用显式 6. 每缓存测命中率；< 80% 说明工作集放不下或 TTL 太短 7. 热键加缓存雪崩防护（single-flight 或抖动 TTL）
示例
数据类型及策略： product_catalog → CDN，TTL 1 时，管理写时清 （静态） user_profile → Redis，TTL 5 分，写透 （近静态） order_status → 不缓存（须实时） （动态） price → Redis，TTL 30 秒，变更显式清 （过时 = 丢钱） 一周后命中率： product_catalog：97%（CDN）✓ user_profile：84% （Redis）✓ price：91%（Redis）✓——前 10 SKU 加雪崩防护
常见问题
- ⚠用一个 TTL 缓一切——动态数据过时、静态数据欠缓存；按数据类型调。
最佳实践
- ✓按缓存层分别测命中率和延迟——95% 命中但 miss 加 50ms 对尾延迟比不缓存更差。
- ✓缓存挂时永远有兜底——系统仍供正确数据只是更慢；别让缓存成硬依赖。