游乐游手机版
首页/AI热点日报/热点详情

唐山本地宝最新开餐饮发票完整流程详解

类型:热点整理2026-07-25
缓存穿透通过参数校验及布隆过滤器拦截无效请求,缓存空值防重复查询;击穿用互斥锁或逻辑过期,仅单个线程重建缓存;雪崩随机化TTL、预热并引入本地缓存分层,避免批量失效。

最近翻看 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 工具,让它按面试官口吻连续追问五轮。第一轮通常还能答,第三轮开始就能看出哪些地方是自己没想明白的。

来源:https://segmentfault.com/a/1190000048073253

相关热点

继续查看同栏目近期热点。

延伸阅读

补充最近整理过的热点入口。