京东面试!百万请求突袭致缓存雪崩?京东8个抗崩技巧,面试答完直接加分!
“系统突然涌入百万并发，缓存集体失效要搞垮服务，你怎么救？”这道京东高频面试题，难倒了90%的求职者！毕竟真实场景里，秒杀抢单、大促峰值、热点事件突发时，一旦缓存“集体罢工”，海量请求会像洪水一样直冲数据库，秒级就能让系统瘫痪——不仅用户骂声一片，公司还可能损失百万营收！别慌！今天分享京东内部正在用的8个“抗崩实战技巧”，从分散压力到分层防御，全程大白话讲解，不管是面试答题，还是工作中踩坑，都能直接用！缓存就像一群同步下班的工人，要是大家同时“过期”，后续请求没人接手，全得冲数据库！解决办法超简单：给每个缓存设置“基础过期时间+随机延时”（比如默认1小时，再随机加0-5分钟）。比如秒杀商品，按商品ID尾号加不同偏移量，让缓存失效时间错开，压力自然被分摊，不会出现“一瞬间全失效”的情况。只靠Redis分布式缓存不够保险，万一Redis部分节点挂了怎么办？搞“双层缓存”兜底：应用本身先存一份本地缓存（比如用Caffeine），再搭配Redis分布式缓存。就算Redis出问题，本地缓存还能顶一阵；而且活动开始前（比如零点秒杀），提前把商品数据加载到两层缓存里，避免请求突然冲过来时“手忙脚乱”。系统就像高速公路，车太多会堵死！必须给它设两道“安全线”：- 限流：用Nginx或网关（比如Spring Cloud Gateway）设阈值（比如每秒最多处理1万请求），多余的请求先排队，不硬扛；
- 熔断：要是Redis或数据库快扛不住了，直接“熔断”——暂时拒绝部分请求，返回“活动太火，稍后再试”，避免整个系统连锁崩溃。
缓存失效时，要是所有请求都冲去查数据库，数据库直接就崩了！这时候用“分布式锁”（比如Redisson）定规矩：让只有一个线程去查数据库、更新缓存，其他线程要么稍等片刻，要么重试；再加上本地缓存的“双重检查”，减少大家抢锁的冲突，效率更高。- 异步更新：把更新操作扔进消息队列（比如Kafka），后台慢慢处理，前台请求该返回就返回，不耽误用户体验；
- 降级策略：实在扛不住时，直接返回兜底数据（比如“活动已结束，感谢参与”），或者用Hystrix让非核心服务“暂时下线”，保住下单、支付这些核心功能不崩。
- 集群化：搞主从复制+哨兵模式，或者Cluster集群，就算某个节点挂了，其他节点能立刻顶上；
- 灾备切换：再部署一套备用缓存集群，主集群真崩了，自动切换到备用集群，业务完全不受影响。
- 永不过期：不设过期时间，靠后台定时更新，或者数据库数据变了就主动刷新缓存，保证一直能用；
- 热点探测：用流计算实时盯着，识别出哪些是“热点Key”（被疯狂访问的Key），自动分散到多个节点或本地缓存，避免一个Key被查崩。
有些请求是“恶意捣乱”——查的是不存在的Key（比如刷接口），要是全冲去数据库，数据库也得累垮！- 布隆过滤器：在缓存前面加一道“过滤网”，提前拦住这些无效请求；
- 空值缓存：就算偶尔漏进来，也给空结果缓存个短时占位符（比如标记“-999”），避免重复去查不存在的数据，让数据库少做无用功。
应对百万级请求，不用搞复杂——核心就是“分散压力、分层防御、快速熔断”：用多级缓存分散请求，用限流熔断挡住超负荷，用锁机制避免数据库被击穿，用异步更新降低瞬时压力。像京东秒杀这样的场景，把预加载、本地缓存、Redis集群和限流结合起来，再加上分布式锁和异步更新，系统自然稳如泰山。这些技巧都是京东实战验证过的，不管是面试答题，还是工作中解决高并发问题，都能直接落地！觉得有用的话，赶紧收藏转发，关注公众号【晨光微微亮】，解锁更多大厂实战干货～
10个月宝宝每天需要喝多少奶粉？
