缓存架构设计 ​

缓存不是「加个 Redis」，而是在每一层决定放什么、什么时候失效、失效了怎么办。 这篇按「放哪 → 怎么读 → 怎么保证一致 → 出问题怎么修」四步讲。

一、缓存放哪一层 ​

浏览器缓存  →  CDN  →  网关/接入层  →  本地缓存（Caffeine）  →  分布式缓存（Redis）  →  DB
   ↑静态资源      ↑静态+动态       ↑鉴权/限流结果        ↑热点数据、字典       ↑共享状态

浏览器缓存  →  CDN  →  网关/接入层  →  本地缓存（Caffeine）  →  分布式缓存（Redis）  →  DB
   ↑静态资源      ↑静态+动态       ↑鉴权/限流结果        ↑热点数据、字典       ↑共享状态

多级缓存的价值：本地缓存挡住 80% 的重复读，Redis 挡住剩下 15%，只有 5% 落到 DB。

代价：每一级都要处理失效。本地缓存尤其难 —— 多实例之间没有共享，只能靠「短 TTL + 广播失效」兜。

二、四种缓存模式 ​

为什么是「删缓存」而不是「更新缓存」：

• 更新缓存在并发下容易写进旧值（两个线程乱序写库，却按顺序写缓存）；
• 删缓存让下次读自然回填，逻辑更短、出错面更小。

三、缓存三大问题（面试必答） ​

1. 穿透：查不存在的数据 ​

现象：请求一个根本不存在的 key，缓存永远不命中，每次都打到 DB。

2. 击穿：热点 key 过期瞬间 ​

现象：一个热点 key 到期，瞬间上万请求同时打到 DB。

// 互斥锁版（最常用）
String v = redis.get(key);
if (v == null) {
    if (redis.setnx(lockKey, "1", 10)) {
        try {
            v = loadFromDb(key);
            redis.set(key, v, ttl);
        } finally {
            redis.del(lockKey);
        }
    } else {
        Thread.sleep(50);
        return get(key);   // 等别人填好再读
    }
}

// 互斥锁版（最常用）
String v = redis.get(key);
if (v == null) {
    if (redis.setnx(lockKey, "1", 10)) {
        try {
            v = loadFromDb(key);
            redis.set(key, v, ttl);
        } finally {
            redis.del(lockKey);
        }
    } else {
        Thread.sleep(50);
        return get(key);   // 等别人填好再读
    }
}

3. 雪崩：大量 key 同时过期 / 缓存整体挂 ​

四、缓存与数据库的一致性 ​

这是最容易被追问的点。先明确：除非用分布式事务，否则做不到强一致，只能做到最终一致。

常见方案的取舍 ​

工程上的常用组合：

写：更新 DB → 删缓存 → 发一条 MQ（延迟 500ms 再删一次）
读：读缓存 → miss 读 DB → 回填（TTL + 随机抖动）
兜底：对账任务每天比对关键数据

写：更新 DB → 删缓存 → 发一条 MQ（延迟 500ms 再删一次）
读：读缓存 → miss 读 DB → 回填（TTL + 随机抖动）
兜底：对账任务每天比对关键数据

为什么删两次：第一次删除后，可能有旧读请求在删除前已经读到旧值、正要回填；延迟第二次删除能把这个回填清掉。

五、热点 key 与大 key ​

热点 key ​

现象：单个 key 的 QPS 打满一个 Redis 节点（Redis Cluster 按 key 分片，热点无法分散）。

大 key ​

判定：String > 10KB、集合元素 > 5000 个。

危害：单次操作阻塞 Redis 主线程（Redis 单线程），网络拥塞。

治理：拆分（hash 分桶）、压缩、改用其他存储（如把大 JSON 放对象存储，缓存只存引用）。

六、缓存容量与淘汰 ​

命中率低于 80% 就要查原因：key 设计不对、TTL 太短、还是根本没热起来。

七、什么时候不要用缓存 ​

• 数据写多读少（缓存只会增加不一致）；
• 数据强一致要求（如账户余额的扣减，缓存只能做只读副本）；
• 访问极度分散（每个 key 只读一次，缓存纯属浪费内存）。

八、速查 ​