最近关注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面试题更重要。