最近在 Java 后端秋招提前批的面经分享中，Redis 相关问题的出现频率相当高。不再是泛泛地问“Redis 有哪些数据结构”，而是直接从项目切入：你简历上写了缓存优化，缓存穿透、缓存击穿、缓存雪崩分别怎么处理？为什么采用这些方案？线上真的实践过吗？

这道题看似是八股文，但很容易被追问到细节。很多人习惯直接背诵“穿透用布隆过滤器，击穿用互斥锁，雪崩加随机过期时间”，面试官再追问两句就答不上来了。

更好的思路是，按照“一次请求如何流转”来组织回答。

先把三种情况区分清楚。
缓存穿透，指的是请求的数据本身就不存在。比如有人持续查询 id 为负数的商品，缓存里没有，数据库里也不存在。每次请求都直击数据库，这才叫穿透。

缓存击穿，指的是某一个热点 key 突然过期。例如首页推荐配置、爆款商品的库存、秒杀活动信息，平时都由缓存扛住，某一时刻 key 失效，大量请求瞬间涌向数据库。

缓存雪崩，是一批 key 在同一时间集体失效，或者 Redis 集群本身短时间不可用。它不是单个热点 key 的问题，而是缓存层大面积失守。

面试时先把这些区别讲清楚，后续才有讨论的基础。如果连击穿和穿透都混为一谈，面试官基本会默认你只是背过题。

穿透：别只提布隆过滤器

第一层处理，其实是参数校验。

如果业务上商品 id 必须为正整数，那么负数、超长字符串、明显不合法的枚举值，应该在入口处就拦截掉。不要让这类请求进入缓存层，更不能进入数据库。

第二层才是缓存空值。数据库查询不到时，可以把空结果也写入缓存，过期时间设短一些，比如几十秒到几分钟。这样同一个不存在的 key 不会反复访问数据库。

布隆过滤器适用于更重的场景：数据集合相对稳定、非法 key 数量庞大、数据库压力已经明显上升。它的特点是可能误判“存在”，但不会把真实存在的数据误判为不存在。因此用它做前置过滤可行，但不能把它当成最终真相。

一个比较稳妥的回答可以这样组织：

先做入参校验，拦截明显非法的请求；
查库为空时缓存空值，避免同一个不存在的 key 重复击穿数据库；
如果非法 key 规模很大，再把合法 id 集合放入布隆过滤器，做前置判断。

如果面试官继续追问“缓存空值会不会污染 Redis”，你可以说空值 TTL 要短、value 要小，并且只对高频不存在的 key 缓存，而不是所有 miss 都无脑写入。

击穿：互斥锁不只是写一个 SETNX

热点 key 过期时，最怕的是大量线程同时查库、同时回写缓存。

常见做法是加互斥锁：只有抢到锁的线程去查询数据库并重建缓存，其他线程稍等后重试，或者直接返回旧值。

这里有个容易踩的坑，别说“SETNX 后再 EXPIRE”。这两个命令分开执行不是原子操作，中间进程挂了就可能留下死锁。Redis 中更推荐用一条 SET 命令带 NX 和 EX 参数，把“只在不存在时设置”和“过期时间”放在同一个原子操作里。解锁时还要校验 value，通常用 Lua 脚本保证只删除自己的锁。

如果业务允许短暂旧数据，逻辑过期方案会更优雅：缓存里不只放数据，还放一个逻辑过期时间。请求来了发现逻辑过期，不是立刻让所有线程查库，而是由一个线程异步刷新，其他请求先拿旧数据顶着。

这在首页配置、排行榜、推荐位上很常见。用户看到几十秒前的数据问题不大，但数据库被打爆就是真事故。

可以这样回答：

强一致要求高的热点 key，用互斥锁重建缓存；
读多写少、允许短暂旧值的热点 key，用逻辑过期加异步刷新；
锁要有过期时间，value 要唯一，删除锁要校验 owner。

这几句话比单独背“互斥锁”更有分量。

雪崩：随机 TTL 只是最低配置

雪崩的典型原因有两个。

一个是大量 key 同时过期。比如你批量导入缓存，全都设置成 30 分钟，半小时后一起失效。这种情况用随机 TTL 就能缓解：在基础过期时间上加一段随机抖动，让 key 分散失效。

另一个是缓存服务本身不可用。这就不是随机 TTL 能解决的了。需要看系统是否有本地缓存、限流、降级、熔断，以及核心数据能否预热。

面试时可以按照层次说明：

过期时间层：TTL 加随机值，避免同批 key 同时失效。
热点数据层：上线或活动开始前进行预热，不等用户请求触发重建。
系统保护层：本地缓存兜底、接口限流、数据库保护、非核心功能降级。

如果你项目里只是普通后台系统，没有高并发活动，也不必硬编秒杀场景。可以说“我没做过秒杀，但在后台字典、配置缓存里会做随机 TTL，避免定时任务批量刷新导致同时过期”。这个回答反而更真实。

面试官真正想听的，不是名词

这道题最后通常会落到项目实践。

如果你的简历写了 Redis，就提前把这几个问题想清楚：

哪些数据用了缓存？为什么这些数据适合缓存？
key 怎么设计？有没有前缀、版本号、业务 id？
TTL 设多久？是固定值还是带随机？
数据更新时，是删缓存、更新缓存，还是延迟双删？
如果缓存没命中，数据库能不能扛住？有没有限流？

这比背十页 Redis 面试题更重要。

准备这类题时，可以把简历里的项目描述丢进面灵 AI，让它按面试官口吻连续追问五轮。第一轮通常还能答，第三轮开始就能看出哪些地方是自己没想明白的。