缓存穿透/击穿/雪崩 + 缓存一致性 · 字节跳动面试官深度拆解

缓存穿透 · 击穿 · 雪崩
+ 缓存与 DB 一致性

字节跳动 · 资深面试官视角 · 从三大缓存问题到一致性方案逐层拆解

🔥 字节必考 TOP3 缓存穿透 · 布隆过滤器缓存击穿 · 互斥锁缓存雪崩 · 随机 TTL Cache Aside 延迟双删订阅 binlog 热 key 问题

面试题

💬 "说说缓存穿透、击穿、雪崩分别是什么？怎么解决？"

考察意图：这是 Redis 面试的标准开场三连。面试官想看你能不能准确区分三者的区别（很多人混淆击穿和雪崩），并且给出具体的解决方案（不是泛泛而谈"加个缓存"）。答好了后面追布隆过滤器实现、互斥锁细节、一致性方案。

扣分回答 ❌

"穿透就是缓存没命中，击穿就是缓存过期了，雪崩就是 Redis 挂了。解决方案就是加布隆过滤器、加锁、做高可用。"

🧠 面试官心理 OS：三个概念的区别没讲清楚——穿透不是"没命中"，是"数据根本不存在"；雪崩不只是"Redis 挂了"，更常见的是"大量 key 同时过期"。解决方案只说了名字没说细节。

满分回答 ✅

缓存穿透——查询的数据在缓存和 DB 中都不存在

比如用户恶意请求 id=-1 的数据，缓存里没有，DB 里也没有，每次请求都穿透到 DB。如果被攻击者利用，高并发下会直接打崩 DB。

解决方案：① 布隆过滤器——在缓存之前加一层布隆过滤器，把所有合法的 key 预加载进去。请求先过布隆过滤器，"可能存在"才继续查缓存和 DB，"一定不存在"直接返回。② 缓存空值——DB 查不到时缓存一个 null/空对象，设较短 TTL（如 30 秒~5 分钟），防止同一个不存在的 key 反复穿透。③ 参数校验——在接口层拦截明显非法的请求（id<0、格式不对等）。

缓存击穿——某个热点 key 过期的瞬间被大量并发请求打穿

热门商品的缓存到期了，瞬间几千个请求同时发现缓存没了，全部去 DB 查并重建缓存——DB 瞬间承受巨大压力。注意击穿是单个热 key的问题，不是大面积。

解决方案：① 互斥锁（Mutex Lock）——缓存未命中时，先用 SETNX 尝试加锁。只有拿到锁的线程去 DB 查并重建缓存，其他线程等待重试或返回旧数据。② 逻辑过期——不设真正的 TTL（key 永不过期），在 value 中存一个"逻辑过期时间"。读到过期数据时，开一个异步线程去重建缓存，当前请求先返回旧数据。③ 热点 key 永不过期 + 后台定时刷新。

缓存雪崩——大面积缓存同时失效，DB 承受全部流量

两种触发原因：① 大量 key 设了相同 TTL，同一时刻集体过期；② Redis 宕机/集群故障，所有请求失去缓存兜底。

解决方案：① TTL 加随机偏移——EXPIRE key (base_ttl + random(0, 300))，让过期时间分散。② Redis 高可用——哨兵模式 / Cluster 模式，自动故障转移。③ 多级缓存——本地缓存（Caffeine/Guava）+ Redis，即使 Redis 挂了本地缓存还能扛一阵。④ 降级 + 限流 + 熔断——DB 扛不住时返回降级数据或默认值，用 Sentinel/Hystrix 做限流。

深入分析 🔬 · 三者完整对比

维度	穿透	击穿	雪崩
数据是否存在	不存在	存在（但缓存过期了）	存在（但缓存大面积失效）
影响范围	针对不存在的 key	单个热 key	大量 key / 整个 Redis
根本原因	缓存和 DB 都没有	热 key TTL 到期	同时过期 / Redis 故障
核心解法	布隆过滤器 + 缓存空值	互斥锁 + 逻辑过期	随机 TTL + 高可用 + 多级缓存
危险程度	中（被攻击时高）	高（瞬间并发）	最高（整体崩溃）

追问①Level 3 · 怎么实现

💬 "布隆过滤器的原理是什么？有什么缺点？"

💡 背景知识：布隆过滤器（Bloom Filter）是一种概率型数据结构，用于判断一个元素"一定不存在"或"可能存在"。它用极小的内存就能判断亿级数据是否存在——100 万个 key 只需要约 1.2MB 内存（误判率 1%）。

回答

原理：一个长度为 m 的 bit 数组 + k 个哈希函数。

写入过程

① 对 key 做 k 次哈希，得到 k 个位置

② 把 bit 数组对应的 k 个位置都设为 1

查询过程

① 对 key 做 k 次哈希，得到 k 个位置

② 检查 bit 数组对应的 k 个位置是否全部为 1

→ 有任何一个为 0 → 一定不存在（100% 准确）

→ 全部为 1 → 可能存在（有误判率——可能是其他 key 把这些位设成了 1）

特性	说明
优点	空间极省（1 亿 key ≈ 120MB，误判率 1%）。查询 O(k) = O(1)。
缺点1	有误判率（false positive）：不存在的 key 可能被判为"存在" → 穿透少量漏网（可接受）
缺点2	不支持删除——一个位可能被多个 key 共享，删一个 key 可能误删其他 key 的位
变体	Counting Bloom Filter 支持删除（每个位用计数器代替 0/1），但占更多空间

Redis 中使用布隆过滤器：

# Redis 4.0+ 通过 RedisBloom 模块支持
BF.RESERVE myfilter 0.01 1000000    # 创建：误判率 1%，预期 100 万元素
BF.ADD myfilter "user:1001"         # 添加 key
BF.EXISTS myfilter "user:9999"     # 查询 → 0(不存在) / 1(可能存在)

# Redisson 也有 RBloomFilter 的 Java 实现
# Google Guava 有本地版 BloomFilter

追问②Level 3 · 怎么实现

💬 "缓存击穿的互斥锁和逻辑过期具体怎么实现？各有什么优缺点？"

💡 背景知识：互斥锁和逻辑过期是解决击穿的两种主流方案。互斥锁保证数据一致性但有等待开销，逻辑过期保证高可用但可能返回旧数据。两者的取舍是面试常追问的点。

回答

方案1：互斥锁（Mutex Lock）

// 伪代码
String value = redis.get(key);
if (value == null) {
    // 缓存未命中 → 尝试获取互斥锁
    if (redis.setnx("lock:" + key, 1, 10)) {  // SETNX + 10 秒过期
        try {
            value = db.query(key);              // 查 DB
            redis.set(key, value, ttl);          // 重建缓存
        } finally {
            redis.del("lock:" + key);           // 释放锁
        }
    } else {
        // 没拿到锁 → 说明有人在重建 → 短暂等待后重试
        Thread.sleep(50);
        return getFromCache(key);             // 递归重试
    }
}

方案2：逻辑过期

// value 中存逻辑过期时间，key 本身永不过期
// 缓存的 value = {"data": 真实数据, "expireTime": 1700000000}

CacheData cache = redis.get(key);     // 一定能拿到（永不过期）
if (cache.expireTime < now()) {
    // 逻辑上已过期 → 异步重建
    if (redis.setnx("lock:" + key, 1, 10)) {
        // 拿到锁 → 开异步线程重建
        executor.submit(() -> {
            Object newData = db.query(key);
            redis.set(key, newCacheData(newData, now() + ttl));
            redis.del("lock:" + key);
        });
    }
    return cache.data;  // 当前请求先返回旧数据（不等待）
} else {
    return cache.data;  // 未过期 → 直接返回
}

对比	互斥锁	逻辑过期
数据一致性	强——等锁拿到最新数据	弱——可能返回旧数据
可用性	低——没拿到锁的线程要等待	高——永远立即返回
实现复杂度	简单	中（需要异步线程 + value 结构改造）
适用场景	数据一致性要求高（如库存、余额）	允许短暂不一致（如商品详情、排行榜）

Part 2 · 缓存与数据库的一致性

缓存三兄弟是"读层面"的问题，一致性是"写层面"的问题——数据修改后，怎么保证缓存和 DB 的数据一致？

这是字节面试中最容易深追的方向——每种方案的漏洞面试官都会挖出来让你分析。

面试题

💬 "缓存和数据库的一致性怎么保证？"

考察意图：这是一道"越追越深"的题。面试官会让你分析每种方案的漏洞：先更新 DB 还是先删缓存？为什么不更新缓存而是删除缓存？延迟双删是什么？最终一致性怎么做？能答到订阅 binlog 的层面就是顶级回答。

追问③Level 2 · 怎么用

💬 "更新数据的时候，是先更新 DB 再删缓存，还是先删缓存再更新 DB？"

💡 背景知识：缓存一致性的核心策略是 Cache Aside Pattern（旁路缓存模式）——读的时候先读缓存，没有则读 DB 并回填缓存；写的时候先更新 DB，再删除缓存。注意是"删除"不是"更新"缓存。

回答

标准答案：先更新 DB，再删除缓存（Cache Aside）

先搞清楚两个"为什么"：

为什么是"删除"缓存而不是"更新"缓存？

更新缓存的两个问题：

① 并发写问题：线程 A 更新 DB 为 10 → 线程 B 更新 DB 为 20 → 线程 B 更新缓存为 20 → 线程 A 更新缓存为 10。结果 DB=20 但缓存=10——不一致！（写写并发时更新顺序不可控）

② 浪费计算：如果缓存的值需要经过复杂计算（如关联多张表），每次写都更新缓存 = 每次都重算，但可能没人读。删除缓存是 lazy 策略——下次有人读的时候再算。

为什么是"先更新 DB 再删缓存"，而不是反过来？

❌ 先删缓存再更新 DB → 有严重的并发问题

T1: 线程A 删除缓存

T2: 线程B 读缓存 → 未命中 → 读 DB（旧值）→ 回填缓存（旧值）

T3: 线程A 更新 DB（新值）

结果：DB=新值，缓存=旧值 → 不一致！且这个旧值会一直存在直到 TTL 过期

✅ 先更新 DB 再删缓存 → 不一致窗口极小

T1: 线程A 更新 DB（新值）

T2: 线程A 删除缓存

T3: 后续请求读缓存 → 未命中 → 读 DB（新值）→ 回填缓存（新值）

结果：一致！

"先更新 DB 再删缓存"也不是 100% 安全——但出问题的概率极低（需要读 DB 比写 DB 慢，几乎不会发生）。而"先删缓存再更新 DB"出问题的概率很高（正常并发就能触发）。

追问④Level 4 · 深入原理

💬 "先更新 DB 再删缓存也有问题吧？删缓存失败了怎么办？"

💡 背景知识：先更新 DB 再删缓存确实有两个漏洞：① 删缓存可能失败（网络抖动、Redis 故障）→ 缓存是旧值。② 极端并发下也可能短暂不一致（但概率极低）。面试官就等着你说完 Cache Aside 后追这两个漏洞。

回答

漏洞1：删缓存失败

更新了 DB 但删缓存时网络抖动 → 缓存还是旧值 → 不一致。

解决方案：重试机制

// 方案A：同步重试（简单但阻塞）
db.update(data);
try {
    redis.del(key);
} catch (Exception e) {
    // 删除失败 → 发到消息队列异步重试
    mq.send("cache-delete-retry", key);
}

// 消费者：从 MQ 拿到 key → 重试删除
// 重试 3 次还失败 → 报警人工处理

漏洞2：极端并发场景（概率极低）

理论上的不一致场景

T1: 线程B 读缓存 → 未命中 → 读 DB（旧值 = 10）

T2: 线程A 更新 DB（新值 = 20）

T3: 线程A 删缓存

T4: 线程B 把旧值 10 回填到缓存

结果：DB=20，缓存=10 → 不一致

但这个场景需要：线程B 的"读 DB + 回填缓存"跨越了线程A 的"更新 DB + 删缓存"整个时间段

即"读比写慢"——数据库写操作通常比读慢，所以读先完成的概率远大于写先完成

实际发生的概率极低，但理论上存在

终极解法（用于高一致性要求场景）：

追问⑤Level 4 · 深入原理

💬 "延迟双删是什么？能解决上面的问题吗？"

回答

延迟双删（Delayed Double Delete）的思路是：更新 DB 后删一次缓存，然后延迟一小段时间再删一次——第二次删除是为了清理在"漏洞窗口"内被回填的旧缓存。

// 延迟双删流程
redis.del(key);                // 第一次删除（可选）
db.update(data);               // 更新 DB
redis.del(key);                // 第二次删除
Thread.sleep(500);             // 延迟 500ms（大于一次读操作的耗时）
redis.del(key);                // 第三次删除 ← 这次才是核心
// 延迟时间 > "读 DB + 回填缓存" 的耗时 → 清掉漏洞窗口内的旧缓存

延迟双删的问题：

① 延迟时间不好定——设太短覆盖不住，设太长这段时间内缓存是空的（相当于击穿）。

② 同步 sleep 不可接受——阻塞了业务线程。要用异步延迟（延迟消息队列 / ScheduledExecutor / Redisson 的延迟队列）。

③ 仍不是强一致——延迟期间还是可能读到旧缓存。

实际生产中延迟双删用得不多——对于大多数业务，Cache Aside + TTL 兜底 + MQ 重试已经够了。真正需要强一致的场景用下面的方案。

追问⑥Level 4 · 深入原理

💬 "有没有更可靠的方案？binlog 订阅是怎么做的？"

💡 背景知识：上面所有方案都是在业务代码中手动删缓存——如果删除操作漏了、失败了、或者有其他系统直接改了 DB 绕过了你的代码，缓存就不一致了。订阅 binlog 方案的思路是：不在业务代码中删缓存，而是由一个独立的服务监听 MySQL 的 binlog，发现数据变更就自动删缓存。

回答

binlog 订阅方案架构

① 业务代码只更新 DB，不管缓存

② Canal / Debezium / Maxwell（binlog 订阅中间件）

→ 伪装成 MySQL 从库，订阅主库的 binlog

→ 解析 binlog 发现数据变更（INSERT/UPDATE/DELETE）

③ 将变更事件发送到 消息队列（Kafka / RocketMQ）

④ 消费者从 MQ 拿到变更事件 → 删除对应的缓存 key

⑤ 删除失败 → MQ 自动重试 → 最终一致性

对比	业务代码删缓存	binlog 订阅删缓存
侵入性	高——每个写操作都要加删缓存逻辑	零——业务代码不用改
覆盖面	只覆盖走了代码的写入（DBA 直接改 DB 就漏了）	任何方式改 DB 都能感知
可靠性	依赖业务代码不出 bug	binlog 是 DB 的"真实来源"，不会漏
延迟	同步删除，延迟极低	异步（binlog 解析 + MQ 投递 + 消费，通常 100ms~1s）
复杂度	低	高（需要部署 Canal + MQ + 消费者）
一致性	最终一致（依赖重试）	最终一致（MQ 保证 at-least-once）

生产中最常见的组合方案：

Cache Aside（先更新 DB 再删缓存）+ TTL 兜底 + 消息队列重试——覆盖 99% 场景。对于核心数据（如库存、余额），再加 Canal 订阅 binlog 做"二次保障"。

追问⑦Level 5 · 陷阱/边界

💬 "热 key 问题怎么处理？和击穿有什么关系？"

💡 背景知识：热 key（Hot Key）是指被大量并发访问的 key——比如秒杀商品、热搜话题。热 key 的问题不只是击穿（过期时的并发重建），还有单节点压力过大——在 Redis Cluster 中，一个 key 只存在于一个节点，所有流量集中打到这个节点可能把它打崩。

回答

热 key 的两个问题：

1. 击穿风险：热 key 过期时瞬间并发打 DB（前面已讲，用互斥锁/逻辑过期解决）。

2. 单节点瓶颈：在 Redis Cluster 中，热 key 所在的节点承受远超其他节点的 QPS → CPU 和网络带宽打满 → 影响同节点的其他 key。

热 key 的解决方案：

方案1：本地缓存（最推荐）

对热 key 在应用服务器本地加一层缓存（Caffeine / Guava Cache），设短 TTL（如 1~5 秒）。大部分请求在本地就命中了，不到 Redis → 彻底消除热 key 的单点压力。

方案2：读写分离 + 多副本

把热 key 复制到多个 Redis 节点：hot_key:1, hot_key:2, ... hot_key:N。读的时候随机选一个副本 → 流量分散到 N 个节点。写的时候广播更新所有副本。

方案3：热 key 探测 + 自动加本地缓存

用 Redis 的 --hotkeys（redis-cli --hotkeys）或 京东 JD-hotkey 等中间件自动探测热 key，发现后自动在应用层加本地缓存。

方案4：永不过期 + 异步刷新

热 key 不设 TTL，后台线程定期从 DB 刷新 → 避免过期造成的击穿。

追问⑧Level 6 · 生产实战

💬 "你们线上缓存一致性是怎么做的？碰到过什么问题？"

回答（典型生产场景）

场景1：先删缓存再更新 DB 导致脏缓存持续一天

现象：用户修改了头像，但页面显示的一直是旧头像（一天后 TTL 过期才恢复）。

原因：代码写的是"先删缓存，再更新 DB"。并发下其他请求在删缓存后、更新 DB 前读到了旧值并回填了缓存。旧缓存的 TTL 是 24 小时。

解决：改成"先更新 DB 再删缓存"（Cache Aside）。同时把 TTL 从 24 小时改成 1 小时——即使出了极端并发问题，不一致最多持续 1 小时。

场景2：删缓存失败导致库存不一致

现象：商品库存明明已经扣减了，但前端显示的还是旧库存。

原因：更新 DB 后删缓存时 Redis 短暂不可用（网络抖动），删除失败了。没有重试机制。

解决：① 删缓存失败后发 MQ 消息异步重试。② 上线 Canal 订阅 binlog 做"二次保障"——即使业务代码的删除失败了，Canal 也会感知到 DB 变更并触发删除。

场景3：缓存雪崩——大促预热缓存同时过期

现象：大促开始后 5 分钟，DB CPU 飙到 100%，大量超时。

原因：运营提前 24 小时预热了 10 万个商品缓存，TTL 统一设了 86400 秒。大促开始恰好 24 小时——10 万个 key 同时过期。

解决：① TTL 加随机偏移量 86400 + random(0, 3600)。② 热门商品设永不过期 + 后台定时刷新。③ 加多级缓存（本地缓存 + Redis），扛住 Redis 缓存穿透的瞬间冲击。

场景4：缓存穿透——恶意请求打崩 DB

现象：凌晨 3 点 DB CPU 异常升高，大量查询 user_id = -1, -2, -3... 的请求。

原因：爬虫或攻击者用不存在的 ID 发大量请求，每次都穿透到 DB。

解决：① 接口层加参数校验（user_id < 0 直接拒绝）。② 上布隆过滤器——把所有合法 user_id 加载到 BloomFilter，非法 ID 直接拦截。③ 对不存在的 key 缓存空值（TTL=60s），防止同一个非法 ID 反复穿透。④ 加 IP 限流（单 IP 每秒不超过 100 次）。

追问⑨Level 4 · 刁难型

💬 "缓存和 DB 能做到强一致吗？"

回答

结论：在分布式系统中，缓存和 DB 无法做到强一致。

根本原因是缓存和 DB 是两个独立的系统，不在同一个事务中。要强一致就要用分布式事务（如 2PC/TCC），但代价极高——每次读写都要跨系统协调，性能会回到"不用缓存"的水平，违背了引入缓存的初衷。

所以缓存一致性的正确心态是：追求最终一致性，控制不一致的窗口时间。

保障层次	手段	不一致窗口
基础	Cache Aside（先更新 DB 再删缓存）	极短（删缓存到下次读的间隙）
兜底	TTL 过期自动失效	≤ TTL 时间（如 1 小时）
重试	MQ 异步重试删缓存	≤ MQ 消费延迟（通常秒级）
终极	Canal 订阅 binlog 删缓存	≤ binlog 解析延迟（100ms~1s）
组合	以上全部叠加	不一致窗口 < 1 秒，且有多层兜底

如果业务绝对不能容忍不一致（如金融余额）——那就不用缓存，直接读 DB。用读写分离 + 连接池 + SQL 优化来扛性能，不要用缓存来换一致性。

追问⑩Level 4 · 深入原理

💬 "新增了用户，布隆过滤器怎么更新？数据怎么初始化进去？"

💡 背景知识：布隆过滤器的数据需要和 DB 保持同步——新增数据要加入过滤器，否则新数据会被误判为"不存在"而被拦截。但布隆过滤器不支持删除——已删除的数据会一直被判为"可能存在"，这不算大问题（最多多查一次 DB）。

回答

初始化：

系统启动时（或定期任务）从 DB 全量加载所有合法 key 到布隆过滤器。百万级 key 用 Redis 的 BF.MADD 批量添加，通常几秒内完成。

# 初始化脚本（伪代码）
all_ids = db.query("SELECT id FROM users")
for batch in chunk(all_ids, 1000):
    redis.execute("BF.MADD", "user_filter", *batch)

增量同步（新增数据）：

方案 A：业务代码同步添加——INSERT 用户成功后，同步调 BF.ADD user_filter new_id。简单直接，但和业务代码耦合。

方案 B：消费 binlog 异步添加——Canal 监听到 INSERT 事件 → 异步 BF.ADD。解耦但有延迟（延迟期间新用户可能被误拦——可以配合"缓存空值"兜底）。

删除数据怎么办？

布隆过滤器不支持删除。用户被删了但布隆过滤器还认为"可能存在" → 查一次 DB 发现不存在 → 返回空。这不会造成穿透——最多多一次 DB 查询（可接受）。如果确实需要删除能力，用 Counting Bloom Filter（每个位用计数器）或 Cuckoo Filter（支持删除，Redis 的 RedisBloom 模块有 CF.* 系列命令）。

追问⑪Level 3 · 怎么实现

💬 "缓存空值和布隆过滤器什么时候用哪个？能一起用吗？"

回答

对比	缓存空值	布隆过滤器
原理	DB 查不到 → 缓存 key=null，设短 TTL	请求前先查过滤器，"一定不存在"直接拒绝
内存开销	高——每个不存在的 key 占一个缓存条目	极低——100 万 key ≈ 1.2MB
对抗能力	弱——攻击者用不同 key 绕过（每个 key 只缓存一次）	强——无论用什么 key 都要过过滤器
实现复杂度	极简——3 行代码	中——需初始化 + 增量同步
适用场景	少量固定 key 穿透（业务 bug、偶发异常）	大量随机 key 穿透（恶意攻击、爬虫）

能一起用吗？当然能，而且推荐组合使用：

组合方案（最佳实践）

① 请求到达 → 先查布隆过滤器

→ "一定不存在" → 直接返回（挡住恶意攻击）

→ "可能存在" → 继续

② 查缓存 → 命中则返回（包括命中空值）

③ 缓存未命中 → 查 DB

→ 有数据 → 回填缓存

→ 无数据 → 缓存空值（TTL=60s，防同一 key 反复穿透）

布隆过滤器挡住大面积随机 key 攻击，缓存空值处理漏网之鱼和布隆过滤器的误判流量。两层防御互补。

追问⑫Level 5 · 陷阱/边界

💬 "拿到互斥锁的线程查 DB 太慢，锁超时了被别人抢了，怎么办？"

💡 背景知识：互斥锁用 SETNX key 1 EX 10 加 10 秒超时。如果持锁线程查 DB 花了 12 秒——锁在第 10 秒自动释放，另一个线程拿到锁也去查 DB 并重建缓存。结果两个线程都在重建，互斥的语义被打破了。这和分布式锁的"超时续期"问题是一样的。

回答

问题本质：锁的过期时间 < 业务执行时间 → 锁提前释放。

解决方案1：锁续期（Watch Dog 思想）

持锁后启动一个后台线程，每隔 TTL/3 检查业务是否完成——没完成就给锁续期。这就是 Redisson 的看门狗（Watch Dog）机制。

// Redisson 自动续期（推荐）
RLock lock = redisson.getLock("lock:rebuild:" + key);
lock.lock();  // 默认 30s 过期，每 10s 自动续期
try {
    value = db.query(key);
    redis.set(key, value, ttl);
} finally {
    lock.unlock();
}

解决方案2：设足够长的锁超时

如果不用 Redisson，就把锁超时设得足够长（如 30~60 秒），远大于"查 DB + 重建缓存"的最大耗时。代价是如果持锁线程真的挂了（OOM、宕机），其他线程要等完整的超时时间。

解决方案3：用锁的 value 标识持有者

SETNX 的 value 用 UUID 标识当前线程。释放锁时先检查 value 是否是自己的——防止"A 的锁超时释放后被 B 拿到，A 完成后误删了 B 的锁"。

// 释放锁时用 Lua 脚本保证原子性
if redis.get(lockKey) == myUUID then
    redis.del(lockKey)
end

生产中直接用 Redisson 最省心——看门狗自动续期 + value 标识 + Lua 原子释放全给你做了。

追问⑬Level 2 · 怎么用

💬 "除了 Cache Aside，还有哪些缓存模式？"

回答

模式	读流程	写流程	特点
Cache Aside （旁路缓存）	读缓存→miss→读DB→回填缓存	更新DB→删缓存	最常用 ⭐ 应用层控制，灵活
Read Through （读穿透）	读缓存→miss→缓存层自动读DB并回填	同 Cache Aside	应用只和缓存交互，缓存层封装了 DB 访问
Write Through （写穿透）	同 Read Through	写缓存→缓存层同步写DB	缓存和 DB 同步写入，数据一致但慢
Write Behind （写回 / 异步写）	同 Read Through	写缓存→缓存层异步批量写DB	写入极快（纯内存），但有数据丢失风险

为什么生产大多用 Cache Aside？

① Read/Write Through 需要缓存层封装 DB 访问逻辑——Redis 本身不提供这个能力，需要额外中间件（如 NCache、Hazelcast 等 JCache 实现），引入复杂性。

② Write Behind 虽然写性能极高，但缓存挂了数据就丢了——对于核心业务不可接受。

③ Cache Aside 把控制权交给应用层，开发者清楚每步在做什么，Debug 容易。

面试金句："Cache Aside 是应用层模式——应用分别和缓存、DB 交互；Read/Write Through 是缓存层模式——应用只和缓存交互，缓存内部封装了 DB 访问。生产中 Cache Aside 最常用，因为 Redis 不是一个内置 DB 访问能力的缓存中间件。"

追问⑭Level 5 · 陷阱/边界

💬 "你说可以加本地缓存做多级缓存，那本地缓存和 Redis 之间怎么保证一致？"

💡 背景知识：多级缓存架构通常是 L1 本地缓存（Caffeine/Guava）+ L2 Redis。问题是：数据更新后删了 Redis 缓存，但每台应用服务器的本地缓存还是旧的——服务器之间互相不知道对方的本地缓存。

回答

核心问题：本地缓存是进程级的，多台服务器各有一份，删 Redis 不会自动删本地。

解决方案：

方案1：Redis Pub/Sub 广播失效通知（最常用）

流程

① 数据更新 → 删 Redis 缓存

② 同时向 Redis 频道发送失效消息：PUBLISH cache:invalidate "user:1001"

③ 每台应用服务器都订阅了这个频道

④ 收到消息后 → 删除本地缓存中对应的 key

缺点：Pub/Sub 不保证消息一定到达（连接断了就丢了）。所以本地缓存必须设很短的 TTL（如 5~30 秒）做兜底。

方案2：本地缓存设极短 TTL

最简单的方案——本地缓存 TTL 设 3~10 秒。即使没收到失效通知，最多 10 秒后就自动过期。适合对一致性要求不高的数据（如商品详情）。

方案3：用现成框架

J2Cache（红薯开源）：L1 Caffeine + L2 Redis，内置了 Redis Pub/Sub 广播失效。Jetcache（阿里）：注解驱动的多级缓存，支持自动刷新和广播。省去自己实现同步逻辑。

我们线上的实践：

热 key 用 L1 Caffeine（TTL=5s，maxSize=1000）+ L2 Redis（TTL=1h）。数据更新时删 Redis + Pub/Sub 广播删本地。即使广播丢了，5 秒后本地缓存也会过期。不一致窗口 ≤ 5 秒，业务可接受。

加分话术 🌟

"面试时如果你能加上这几句话，面试官会对你印象特别好："

💬 "穿透/击穿/雪崩的区分：穿透是'数据不存在'——子弹穿墙而过；击穿是'一个热 key 过期'——一颗子弹击穿一个薄弱点；雪崩是'大面积过期或 Redis 宕机'——整面墙倒塌。三者的根因和解法完全不同。"

💬 "缓存一致性的标准方案是 Cache Aside——先更新 DB 再删缓存。不是'更新'缓存而是'删除'——因为更新缓存在并发写时会出现顺序错乱，删除是 lazy 策略，下次读时再重建。"

💬 "'先删缓存再更新 DB'有严重的并发问题——删缓存后、更新 DB 前，其他线程会把旧值回填到缓存。'先更新 DB 再删缓存'的不一致窗口极小（需要读比写慢，几乎不发生）。所以业界标准是后者。"

💬 "缓存和 DB 无法做到强一致——它们是两个独立系统，没有统一事务。正确的做法是追求最终一致性，用多层兜底：Cache Aside + TTL + MQ 重试 + Canal 订阅 binlog。叠加后不一致窗口 < 1 秒。"

💬 "热 key 的问题不只是击穿——在 Redis Cluster 中，热 key 会导致单节点 QPS 过高。解法是本地缓存（Caffeine）做一级缓存，大部分请求不到 Redis。京东的 JD-hotkey 可以自动探测热 key 并加本地缓存。"

💬 "我们线上的缓存一致性方案：Cache Aside + TTL 1 小时兜底 + 删缓存失败发 MQ 重试 + 核心数据上 Canal 订阅 binlog 二次保障。出过一次运营预热缓存同时过期的雪崩，之后所有 TTL 强制加 random(0, 600) 偏移。"

追问 · 深水区Level 5 · 陷阱/边界

💬 "为什么推荐先更新 DB 再删缓存，而不是反过来？"

💡 核心结论：两种顺序在并发下都有不一致的风险，但"先更新 DB 再删缓存"出现不一致的概率极低（需要缓存刚好过期 + 读比写快的极端巧合），而"先删缓存再更新 DB"出现不一致的概率很高（常规并发就会触发）。

方案 A（不推荐）：先删缓存，再更新 DB

步骤	线程 A（写）	线程 B（读）	缓存状态	DB 状态
1	删除缓存 ✅		空	旧值
2		读缓存 miss → 读 DB → 读到旧值	空	旧值
3		把旧值写入缓存	旧值（脏数据！）	旧值
4	更新 DB 为新值 ✅		旧值（脏！）	新值

⚠ 结果：DB 是新值，缓存是旧值 → 不一致！且在缓存 TTL 过期前一直读到脏数据。这种场景在正常并发下非常容易触发。

方案 B（推荐）：先更新 DB，再删缓存（Cache Aside）

步骤	线程 A（写）	线程 B（读）	缓存状态	DB 状态
1	更新 DB 为新值 ✅		旧值	新值
2	删除缓存 ✅		空	新值
3		读缓存 miss → 读 DB → 读到新值	新值	新值

✅ 正常流程完全一致。理论上唯一出问题的场景是：步骤1和2之间恰好有读请求 + 缓存刚好过期 + 读DB比写DB先返回——这个巧合概率极低。

追问 · 补充Level 4 · 生产实战

💬 "延迟双删的延迟时间怎么定？如果所有方案都失败了怎么兜底？"

延迟双删的核心问题——延迟时间没有精确答案：

延迟时间应略大于"一次主从同步延迟 + 一次业务读请求耗时"，通常设 300ms~1s。但这个值只能凭经验估算，设小了不一致没消除，设大了写请求延迟高。所以延迟双删只能降低不一致概率，无法做到强一致。

生产中更推荐的方案——订阅 binlog（Canal + MQ）：

Canal 监听 MySQL binlog → 解析出变更的行 → 发送到 MQ → 消费者删除/更新对应的缓存。优势：解耦（业务代码不用管缓存）、可靠（MQ 重试保证最终一致）、低延迟。

兜底方案（所有方案都可能失败时的保底措施）：

兜底层级	方案	效果
第一层	给缓存设合理 TTL（如 30 分钟）	即使不一致，TTL 过期后自动恢复 → 最终一致性
第二层	定时任务对比 DB 和缓存的差异并修正	定期全量校验，发现不一致主动修复
第三层	缓存不可用时降级直读 DB + 限流	保证可用性，DB 不被打崩

💡 面试中的标准答案："分布式环境下无法保证缓存和 DB 的强一致性，只能通过合适的策略降低不一致的概率和持续时间。如果业务要求强一致性，就不应该用缓存。"

延伸面试题 📚

以下是面试官可能继续追问的方向：

缓存穿透 · 击穿 · 雪崩+ 缓存与 DB 一致性