缓存穿透、缓存击穿、缓存雪崩的区分与完整解决方案

发布时间：2026/6/13 1:07:24

一、核心区分问题核心特征触发场景简单理解缓存穿透查不存在的数据缓存 DB 都无数据请求直打 DB非法 ID、恶意遍历、空数据查询穿过去两边都没数据缓存击穿热点 Key 突然失效大量并发同时打向 DB秒杀商品、首页热点、固定热点缓存过期一个热门 Key 崩了并发扎进 DB缓存雪崩大量 Key 集体失效 / 缓存服务宕机全量请求压垮 DB缓存同一时间批量过期、Redis 集群挂掉整片缓存全挂流量全部冲数据库二、详细讲解 对应解决方案一、缓存穿透1. 成因查询数据库根本不存在的数据前端传非法 ID负数、超长 ID、随机乱 ID爬虫 / 恶意攻击遍历 ID如id1,2,3...批量扫库业务空数据用户已删除、订单已销毁链路请求 → 缓存未命中 → 查询数据库 → 无数据 → 不写缓存 → 下次请求重复走 DB。高并发下DB 压力持续暴涨。2. 解决方案按推荐优先级方案 1空值缓存最简单业务首选逻辑DB 查询为空时依然往缓存写入一个空标记设置较短过期时间5~10 分钟。优点实现简单、防穿透效果明显缺点会占用少量缓存空间极端恶意请求会产生大量空 keyjava// 伪代码String key order: orderNo;String cacheVal redis.get(key);if (cacheVal ! null) {return .equals(cacheVal) ? null : cacheVal;}// 查询DBOrder order db.select(orderNo);if (order null) {redis.set(key, , 600); // 空值10分钟过期return null;}redis.set(key, JSON.toJSONString(order), 3600);return order;方案 2布隆过滤器高并发、海量数据推荐原理把所有合法业务 ID提前存入布隆过滤器请求先过过滤器。流程请求 ID → 布隆过滤器判断不存在→ 直接拦截不查缓存与 DB。适用订单、用户、商品等固定合法数据集。特点优点彻底拦截非法请求性能极高缺点存在误判不会漏判数据新增 / 删除需要维护过滤器不适合频繁变动数据方案 3接口层参数校验前置拦截限制 ID 规则ID 必须正数、长度范围、格式校验黑名单、IP 限流恶意 IP 直接封禁适用网关 / 拦截器统一前置从源头减少无效请求方案 4Redis 布谷鸟过滤器进阶弥补布隆过滤器不能删除的问题适合数据频繁增删场景。二、缓存击穿1. 成因单个热点 Key到期失效瞬间海量并发请求同时绕过缓存直达数据库。典型场景秒杀商品、爆款商品、首页活动、高频查询订单。关键点只有一个热点 Key 失效不是批量失效。2. 解决方案按推荐优先级方案 1互斥锁分布式锁通用稳定主流Redis 分布式锁保证同一时刻只有一个请求查 DB 回写缓存其余请求等待重试。流程缓存失效尝试加分布式锁抢到锁 → 查询 DB → 写入缓存 → 释放锁未抢到锁 → 短暂休眠后重试读缓存优点通用、可靠几乎无业务侵入缺点并发极高时会有少量等待影响一点吞吐量java// 伪代码Redis 分布式锁String key hot:goods:1001;String lockKey lock:hot:goods:1001;String val redis.get(key);if (val ! null) {return val;}// 尝试加锁boolean lock redis.tryLock(lockKey, 30);if (lock) {try {// 查询DBString dbData db.query();redis.set(key, dbData, 3600);return dbData;} finally {redis.unLock(lockKey);}} else {// 短暂休眠后重试Thread.sleep(50);return redis.get(key);}方案 2永不过期热点 Key 专用最优对绝对热点、数据更新不频繁的 Key不设置过期时间。手动更新 / 后台定时任务更新缓存杜绝过期击穿。适用首页配置、爆款商品、基础配置数据。优点零击穿风险、性能最高缺点数据更新存在延迟内存占用持续存在方案 3热点 Key 逻辑永不过期续期代码层面判断即将过期后台异步主动刷新前端无感知。方案 4多级缓存本地缓存 RedisCaffeine/Guava 本地缓存 Redis 二级缓存。热点数据留在 JVM 本地请求根本不打到 Redis彻底规避击穿。优点性能拉满缺点多实例存在数据不一致适合允许短时间不一致的场景三、缓存雪崩1. 两类成因必须分清类型 A大量缓存 Key 同时过期批量 Key 设置了相同过期时间同一时刻集体失效流量全压 DB。类型 BRedis 服务整体宕机 / 不可用Redis 集群断电、主从故障、网络分区所有缓存全部不可用流量直接冲垮 DB。击穿是单点热点 Key雪崩是整片缓存。2. 解决方案分两类场景场景 A解决「批量 Key 同时过期」方案 1过期时间加随机值最简单必用原有过期时间 随机偏移量1~10 分钟打散过期时间避免集体失效。java// 原 3600秒增加 0~600 随机秒int expire 3600 new Random().nextInt(600);redis.set(key, value, expire);优点零成本、线上直接改基础兜底方案方案 2分层过期、错峰更新按业务模块划分不同过期时间避免全模块同时刷新。场景 B解决「Redis 集群宕机」核心高可用方案 1Redis 高可用架构基础保障主从 哨兵Sentinel主节点挂掉自动切换从节点Redis Cluster 集群分片 多副本部分节点故障不影响整体生产环境强制部署不能单机 Redis。方案 2多级缓存降级本地缓存兜底JVM 本地缓存Caffeine作为二级缓存。Redis 挂了请求走本地缓存保护 DB。注意接受多实例短暂数据不一致。方案 3服务熔断 限流 降级网关 / 层防护结合 Sentinel / Resilience4j / Hystrix限流限制每秒请求总量防止流量打爆 DB熔断DB 异常时直接熔断不再向下游请求降级返回默认值、静态页面、提示文案放弃实时数据方案 4缓存预热系统启动、大促前提前批量加载热点数据进缓存避免冷启动雪崩。三、三者对比总结缓存穿透问题查不存在的数据典型非法 ID、爬虫遍历首选方案空值缓存 参数校验海量数据用布隆过滤器2.缓存击穿问题单个热点 Key 过期并发打 DB典型秒杀、爆款商品首选方案分布式锁 / 热点 Key 永不过期3.缓存雪崩问题大量 Key 同时过期 或 Redis 整体挂掉典型统一过期时间、Redis 宕机首选方案过期加随机值 Redis 高可用 限流熔断降级四、电商 / 支付业务落地组合方案全链路前置网关参数校验 IP 限流防穿透源头防穿透空值缓存5 分钟过期 布隆过滤器订单 ID 集合防击穿支付热点订单 / 爆款商品 →Redis 分布式锁 热点 Key 不主动过期防雪崩所有缓存过期时间加随机偏移Redis 部署 Cluster 集群 哨兵接入 Sentinel 做限流、熔断、降级