缓存与读扩展
缓存层、CDN;衔接 redis-essentials。
30 分钟
缓存与读扩展
读多写少的接口,数据库往往是第一个瓶颈。缓存 把热点数据放在更快的介质(内存、CDN 边缘),用空间换时间,是成本最低的读扩展手段。本课衔接 redis-essentials,落实 building-for-scale 中的读路径优化。
学习目标
- 区分浏览器缓存、CDN、应用缓存、数据库缓冲池四层
- 掌握 Cache-Aside 模式及穿透、击穿、雪崩三类问题
- 为热点接口设计合理的 TTL 与失效策略
核心概念
典型读路径:
Client → CDN → App → Local Cache → Redis → DB
| 模式 | 流程 | 适用 |
|---|---|---|
| Cache-Aside | 先查缓存,miss 再查 DB 并回填 | 通用业务读 |
| Read-Through | 缓存层代理 DB 读 | 封装好的缓存 SDK |
| Write-Through | 写同时更新缓存 | 强一致读少写 |
三大经典问题:
- 穿透:查不存在的数据,缓存永不命中 → 布隆过滤器 / 空值短 TTL
- 击穿:热点 key 过期瞬间打穿 DB → 互斥锁 / 逻辑过期
- 雪崩:大量 key 同时过期 → TTL 加随机抖动
// Cache-Aside 伪代码
User u = redis.get(key);
if (u == null) {
u = userRepo.findById(id);
if (u != null) redis.setex(key, u, ttl + random(0, 60));
}
本地缓存(Caffeine)适合极热、允许短暂不一致的数据;跨实例一致用 Redis。CDN 适合静态资源与可公开 API 响应。
与可靠性
缓存不是 DB 替身:必须有 降级到 DB 与 限流 预案,见 reliability-essentials 与 scale-backpressure。
练习
- 选一个读多写少 API,估算缓存命中率 90% 时能少多少 DB QPS
- 为商品详情设计 key 命名、TTL、穿透防护三要素
- 完成 redis-essentials 中 String/Hash 相关练习
小结
缓存是读扩展的杠杆:命中率高则 DB 压力骤降,但要主动治理穿透、击穿与雪崩。
加载本节练习…