Redis缓存穿透击穿雪崩实战：故障链路与有效方案-北京尧图网络

Redis缓存穿透、缓存击穿、缓存雪崩这三个词在我看来是后端面试的标配也是线上事故的常客。我见过太多能把三者的定义倒背如流的人但真到告警弹出的那一刻还是会认错问题——以为是穿透查了半天发现是击穿雪崩已经发生了还在逐个key排查。这篇不重复教科书定义只讲我在真实项目里踩过的坑、用过的方案和最终的取舍逻辑。如果你正在维护一套带Redis的读多写少系统或者准备给服务加缓存但担心被这几个问题“教做人”这篇值得认真看完。我会把每个问题的故障链路先捋清楚再给可落地的方案和参数最后聊一聊监控与选型——因为很多坑提前用监控接住根本不用等它爆。1. 三个问题为啥总被搞混从故障链路看穿透、击穿、雪崩的本质区别很多人搞混这三个概念是因为只看结论、不看请求链路。其实这三者的故障特征差异非常明显只要盯着“DB收到的请求长什么样”去还原现场基本不会认错。1.1 穿透缓存和数据库里都没有的“幽灵请求”缓存穿透最典型的一个例子商品详情接口调用方传了一个不存在的商品ID比如-1或者一个根本不在库里的随机数字。请求到了服务端先查Redis——没有这个key于是去查MySQL——也没这条记录查完之后因为结果为null我们通常不会把这个空结果写回缓存。那么下一次同样的请求过来Redis依然查不到DB又要再扛一次。如果这种请求只有零星几次DB完全无所谓。问题出在攻击者或爬虫用脚本批量构造不存在的ID比如一个循环从100000随机拼到999999这部分ID大量都不存在。于是Redis完全起不到拦截作用所有请求都打在了DB上连接数、慢查询、CPU全部飙升。穿透的核心特征就一句话请求访问的key在Redis和DB里都不存在每一次都会漏到DB。它不是“缓存失效导致的”而是“缓存根本拦不住这个key”。这也是它区别于击穿和雪崩最根本的地方。排查穿透事故时我习惯打开DB慢查询看SQL的WHERE条件里是不是集中出现一批明显不存在的ID。如果有基本可以判定是穿透。另外一个信号是Redis的QPS变化不大但DB的QPS暴涨而且接口错误率也在涨——这种情况大部分就是穿透。1.2 击穿单个热点 key 失效瞬间的请求漏斗击穿的场景和穿透完全不同。数据在DB里是存在的Redis里本来也缓存得好好的但某个热点key的TTL恰好在这一刻到期了。举个例子一个秒杀商品的详情页平时这个key在Redis里扛着几万QPS突然TTL到了Redis里的数据被删除。接下来一秒内成千上万的请求同时来查这个key全部miss于是大家一起涌向DB。为什么叫“击穿”因为缓存明明存在却在某个点位上被戳了个洞所有的流量从这个洞漏过去了。故障时间窗口往往很短可能只有几百毫秒到几秒但只要DB在这一瞬间被打垮影响就被放大成几分钟甚至更久——连接池被打满、主从延迟、其他接口全部跟着遭殃。击穿和穿透最容易混淆的地方在于两者的表象都是“Redis没查到DB扛了高并发”。但穿透是key不存在击穿是key存在但刚好过期穿透的请求是“每时每刻都漏过去”击穿的请求是“集中在一个极短的时间窗口”。排查击穿有个很有效的办法去看看出问题的那个key是不是热点key再对比它的过期时间是不是刚好落在故障时间点前后。如果是再结合DB日志里大量相同的查询条件基本就能锁定是击穿。1.3 雪崩多个 key 同时失效或者 Redis 整体不可用雪崩的杀伤力比前两个大得多因为它影响的不再是“某一个key”或“某一类不存在的key”而是缓存体系的整体失灵。雪崩最常见的诱因有两个。第一个是批量key在同一时间到期。很多项目初始化缓存时习惯把TTL设成一个固定值比如3600秒。那么每天到整点的时候这批key会一起从Redis里消失所有请求同时落到DBDB压力瞬间飙升。这种情况常见于配置类缓存、价格缓存、或者定时任务批量刷新的列表缓存。第二个是Redis实例本身不可用。比如机器宕机、网络分区、主从切换期间服务不可用极端情况下内存被打满导致OOM。这时所有原本应该命中缓存的请求全部miss直接砸向DB。有句话说得好不用Redis的时候DB还能撑住用了Redis之后Redis一挂DB反而先挂——就是这个道理。所以雪崩的定位很明确它不是单个key的问题而是“批量失效”或“整体失效”的问题。应对思路也必须上升到架构层面错峰、分层、高可用、降级一个都不能少。2. 拦截穿透请求布隆过滤器不是唯一答案空值缓存和入参校验也很关键聊解决方案之前先说一句穿透的应对手段很多但很多团队一上来就上布隆过滤器其实没必要。方案选型要看请求特征有些场景一个简单的参数校验就能干掉90%的问题。2.1 布隆过滤器位数组与哈希函数的组合原理布隆过滤器适合那种“key空间很大、但实际存在的key很少”的场景。它的原理不复杂初始化一个bitmap位数组往里添加一个key时用k个哈希函数算出k个位置把这k个位置都置为1判断一个key是否存在时同样算k个位置只要其中有一个位置是0说明这个key一定不存在。为什么说“一定不存在”因为如果key真的存在过那k个位置一定都被置为1了。反过来如果k个位置都是1只能说明“可能存在”因为其他key的哈希结果可能把位置占满了这就是误判。布隆过滤器有两个关键参数位数组大小m和哈希函数个数k。公式是m - (n * ln p) / (ln 2)^2k (m / n) * ln 2其中n是预期存储的数据量p是能接受的误判率。举个例子n1000万p1%算出来的m约9585万bit换算下来大约11.4MB内存k约等于6.64取7个哈希函数。也就是说用11MB左右的内存和7次哈希计算就能用一个不太高的误判率把“不存在”的key拦在缓存前面。这个成本放在真实项目里是完全能接受的。但要注意两点第一布隆过滤器用起来不是懒加载就完事的你要在数据写入DB时同步更新布隆过滤器第二布隆过滤器不能删除key数据下架了它里面还留着所以需要定期重建或者用带计数器的Counting Bloom Filter来支持删除。重建的常规做法是低频时期基于DB全量数据重新构建一份再平滑切换。我见过的误用案例是有人把布隆过滤器放在Redis缓存之后、DB之前这样布隆可以拦掉一部分穿透请求但命中的key还得走一遍Redis收益被打了折扣。正确的位置应该尽量靠前一般放在业务查询入口或网关层Redis之前。2.2 空值缓存实现简单但有三个必须注意的细节空值缓存是穿透方案里最朴素也最实用的一种逻辑一句话就能说清DB查询结果为空时往Redis里也写一个值TTL设短一点下次同样的key来了直接在缓存层拿到空结果不再打DB。但这个方案有三个细节必须注意否则容易从“防穿透”变成“埋雷”。第一TTL不能太长。我一般设置3到5分钟时间太长会累积大量无效key白白占内存。如果有人恶意构造随机ID每个ID都写一个空值Redis里会堆出一大堆垃圾key直接影响性能和内存使用。第二空值必须能跟真实数据区分。我习惯统一用NULL或EMPTY作为占位符读出来的时候要做判断不能直接把占位符当正常数据返回给调用方。看起来像是小事但真有人在JSON序列化的时候把null和NULL搞混过导致接口返回了奇怪的字符串。第三当真实数据写入时必须同步删除空值缓存。举个最常见的场景某个用户ID查出来是不存在的系统把它空值缓存了过一会儿用户注册成功真实记录写进DB但如果空值缓存没删别人再查这个ID还是返回“用户不存在”。这个一致性问题比缓存过期还要隐蔽因为TTL一到也会恢复但在这期间用户已经受到影响了。空值缓存比较适合key空间可控、不存在key总量有限的业务。比如用户ID、订单ID这类有规律、有范围的场景。如果攻击者直接用UUID、雪花算法生成大量随机key空值缓存就不太够看因为空值写入速度可能跟不上攻击速度垃圾key还会堆积——这种场景让布隆过滤器在前面挡才是正解。2.3 入参校验和限流第一道门的成本最低有很多穿透事故根源不是没有布隆过滤器而是连最基本的参数校验都没做。一个商品详情的ID传负数、传0、传超长字符串按理说应该在接口层直接被拦截掉结果很多系统图省事直接塞进Redis和DB查询逻辑里。我在项目里给团队定的规矩是所有读接口在进入缓存逻辑之前先做参数合法性校验非法参数直接返回400或者默认空结果不进Redis、不进DB。这一步几乎零成本却能把最粗暴的一批扫描请求拦住。限流也是穿透防线里不能省的一环。布隆过滤器能拦截不存在的key但没法拦截“所有key都不存在”的持续扫描行为。给同一个IP、同一个参数维度做限流尤其是滑动窗口限流能让恶意请求的速率降下来。实现上直接用Redis的INCR加过期时间就能做一个简单的窗口计数器或者用现成的限流组件。参数校验解决“明显非法”限流控制“访问速率”布隆过滤器拦截“不存在的key”空值缓存兜底“少量漏网之鱼”。这几层叠加起来穿透才能真正意义上的被压住而不是单点依赖某个高级组件。3. 热点 key 过期的并发风暴互斥锁与逻辑过期谁更适合线上击穿的处理方案主要分两派一派是互斥锁让并发请求排队只放一个线程去DB重建缓存另一派是逻辑过期先把旧值返回给用户后台异步重建缓存。两派各有适用场景选错很容易出问题。3.1 互斥锁方案setnx double check 的完整代码链路互斥锁的思路很简单发现缓存miss之后先尝试获取一把针对这个key的分布式锁抢到锁的线程去查DB、写缓存其他线程等待锁释放后再重新读缓存。下面是一段Java伪代码我把关键点标出来public String getWithLock(String key) { // 第一次查缓存 String value cache.get(key); if (value ! null) { return value; } // 抢锁只对当前key加锁 String lockKey lock: key; boolean locked redis.set(lockKey, 1, NX, EX, 3); if (locked) { try { // double check抢到锁后有可能其他线程已经重建过缓存 value cache.get(key); if (value ! null) { return value; } // 真正回源DB value queryDB(key); // 写缓存 cache.set(key, value, EX, 300); return value; } finally { // 释放锁前校验value防止误删其他线程的锁 String luaScript if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; redis.eval(luaScript, lockKey, 1); } } // 没抢到锁等待后递归重试 Thread.sleep(50); return getWithLock(key); }这段代码有几个地方值得说道。首先是加锁用的命令SET key value NX EX 3。NX表示只有key不存在时才设置成功EX 3表示锁的自动过期时间是3秒。这比“SETNX EXPIRE”两条命令的方式安全因为两条命令在极端情况下中间可能宕机锁变成永久锁。其次是double check。抢到锁不代表缓存一定还是空的极端情况下两个线程都发现cache miss但第一个线程已经把缓存重建好了第二个线程才抢到锁。如果不做二次检查就会出现重复查DB的情况锁的意义就打了折扣。然后是释放锁的Lua脚本。为什么不能直接DEL因为锁的过期时间只有3秒如果线程A执行DB查询耗时超过了3秒锁自动过期了线程B抢到了同一把锁等线程A执行完它如果直接DEL lockKey就会把线程B的锁误删。用Lua脚本先GET判断value是不是自己的是才DEL能把这个风险完全消除。最后是拿不到锁时的策略。简单粗暴的递归重试虽然能跑但要注意退避。我一般sleep 50毫秒最多重试8次左右如果还是拿不到锁就走降级逻辑返回默认值而不是无限循环把线程全卡住。这里也引出一个考量互斥锁方案会让一部分请求多等几十毫秒如果业务对响应时间要求很苛刻就得看下面的逻辑过期方案了。3.2 逻辑过期方案旧值先返回、新值后台重建逻辑过期方案的核心公式是缓存key不设TTL但value里带一个逻辑过期时间字段。查询时发现逻辑过期时间已到并不删除缓存而是先把旧值返回给调用方同时触发一个后台任务去重建缓存。value的格式长这样{ data: 商品详情内容, logicExpireTime: 1730000000000 }查询逻辑是public String getWithLogicExpire(String key) { String json cache.get(key); if (json null) { // 缓存完全不存在说明是穿透或首次查询仍要回源DB return queryDBAndBuildCache(key); } CacheValue cacheValue parse(json); if (cacheValue.logicExpireTime System.currentTimeMillis()) { // 逻辑过期时间还没到直接返回 return cacheValue.data; } // 逻辑过期已到先返回旧值再异步重建 asyncBuildCache(key); return cacheValue.data; }这个方案最大的优势是热点key在过期瞬间不会产生任何等待所有请求都能立刻拿到旧值返回响应时间几乎不受影响。旧值可能已经过时几秒钟或几分钟但对于商品详情、资讯列表这类内容型业务用户完全感知不到差异。代价也在这里数据一致性变弱了。如果你的业务要求读到的数据必须是最新的比如库存、订单状态、账户余额逻辑过期方案就是灾难。另外异步重建任务需要一个统一管理的线程池或定时任务框架你不能每一次请求都起一个线程去建缓存那会把应用服务器的线程池打满。通常的做法是后台常驻一个刷新线程扫描到快要过期的key就批量刷新。我一般的原则是读多写少、对短暂旧数据容忍度高的场景优先逻辑过期需要严格一致性的场景老老实实用互斥锁或者干脆不缓存。3.3 热点探测与预热把击穿时刻提前消解掉不管选哪种方案最好的击穿治理其实是“别让它发生”。怎么做到核心是热点探测和主动预热。热点探测是在常态化运营中识别出哪些key的访问量特别高。手段有几个在业务代码里做本地LFU统计维护一个小型的热点key清单利用Redis的hotkeys命令扫描或者在网关层按key维度做流量统计。识别出来的热点key可以在活动开始前主动写入多级缓存提前把缓存热度拉起来。拿电商大促举例运营提前一周就能确定哪些商品会重点推。把这些商品的ID整理成热点清单在活动开始前把详情、价格、库存快照等数据预热到本地缓存和Redis里同时给这些key设置逻辑过期而不是固定TTL。这样就算活动瞬间涌入百万请求也不会出现“大量请求到Redis才找到缓存”的情况更不会一窝蜂打DB。热点的另外一个处理技巧是差异化的TTL普通key正常设置过期时间热点key单独设置更长TTL或者干脆不设置TTL走逻辑过期。这样能让有限的Redis内存花在真正高价值的key上。4. 雪崩防护不能只靠随机 TTL多级缓存、实例高可用、降级熔断的组合方案雪崩防护和穿透、击穿完全不同它不是“加一个组件”就能解决的而是系统工程。从成本最低的随机TTL到本地缓存兜底再到Redis高可用和降级每一层解决的场景都不一样。4.1 随机 TTL 错峰让失效时间在时间轴上重新分布随机TTL是应对批量失效最简单有效的手段实现上也几乎零成本。原来所有key都是EX 3600现在改成EX 3600 random(0, 600)。别小看这10分钟当缓存里有十万个key时它们的过期时间就从“同一个点”变成了“均匀分布在一个区间内”DB再也看不到那种整点整刻的尖峰。这里有一个细节我特别提醒随机范围要和业务波动周期匹配。如果业务高峰是每小时的整点那随机范围至少要覆盖整个小时比如600秒甚至900秒效果才明显。只加个30秒的随机高峰期稍微错开一点DB压力没什么本质变化。随机TTL也有解决不了的场景活动类的批量缓存业务上要求它们在同一时刻失效比如“0点刷新首页推荐位”。这种情况下你没法用随机TTL错峰只能改用“永久key 定时任务主动刷新”的方案让缓存数据的内容在0点这一瞬间被替换但key本身不失效。这其实就是一种业务层的“逻辑过期”思路。4.2 多级缓存兜底本地缓存作为最后一道缓存屏障多级缓存是雪崩防护里我认为性价比最高的一层应用本地放一个Caffeine或Guava缓存查询顺序从“只查Redis”变成“查本地缓存 → 查Redis → 查DB”。结构上是这样的请求 - 本地缓存(Caffeine) - Redis - DB本地缓存适合放两类数据一类是热点key比如热销商品详情另一类是长期不变的配置数据。内存容量不要设太大我习惯的方式是maximumSize控制在10000到50000之间expireAfterWrite设置30到60秒。为什么要加这么短的过期时间因为本地缓存多了一致性问题如果本地缓存TTL太长Redis里的数据已经更新了应用节点可能还在对外播报旧数据。TTL短一点最多几十秒的不一致大部分业务是可以接受的。本地缓存在雪崩里的价值是当Redis出现故障时每个应用节点还有一层能挡住部分请求。假设你有10个应用节点每个节点本地缓存能扛1000 QPS那即使Redis完全不可用应用层还能挡住10000 QPSDB不会瞬间被打满。这就是给系统争取到了降级和恢复的时间。4.3 Redis 高可用与快速恢复把宕机时间压缩到分钟级光有应用层的兜底还不够Redis自身的高可用也要做。生产环境我建议至少采用主从复制加哨兵的模式或者数据量、分片需求大的直接用Cluster。主流一些的做法是Cluster三主三从起步主节点挂了自动故障转移Redis的不可用时间能压缩到几十秒到分钟级。但必须清醒一点高可用不等于“Redis永远不会挂”。故障转移期间哪怕只有几十秒缓存请求全部失败如果应用没有降级逻辑这几秒钟照样能把DB压垮。所以高可用方案一定得和降级方案搭配使用。一个常见但不被重视的坑是内存淘汰策略。如果实例内存不够且配置的是allkeys-lruRedis在内存压力下可能随机淘汰热点key。原本那些高QPS的key突然全部miss效果和雪崩几乎一样。建议热点缓存单独用一台实例或者在使用LRU策略的同时加上监控随时盯住内存水位。4.4 服务降级与兜底数据业务上允许返回旧版本还是默认值降级是整个雪崩防护的最后一层兜底也是很多团队容易忽略的一层。Redis不可用、DB又扛不住的时候系统必须有能力给用户一个相对完整的响应而不是一个超时错误。实操上我会给每个核心读接口定义一份“最低可用数据”。以商品详情为例最低可用数据是商品标题、主图、价格、库存状态——这些字段可以来自本地缓存的快照也可以来自静态配置。一旦下游缓存和DB都出现异常接口直接返回这份快照宁可数据旧一点也不能让整条链路全部失败。熔断也必不可少。当DB的错误率或超时率达到阈值比如连续20次失败就对DB查询做短路直接走降级路径让DB有时间恢复。这和使用Sentinel或Hystrix这类组件是一个道理。降级开关和熔断阈值一定要定期演练不能只在复盘PPT里存在。我见过太多次“降级逻辑写了但从来没触发过真到触发时发现代码路径有bug”的情况。5. 选型之前先看监控命中率、慢查询和 P99 才是指挥棒走到这一步方案的基本盘已经聊完了。最后我想把视角拉高一点聊一聊方案选型背后真正的指挥棒——监控数据。没有监控的缓存治理就是盲人摸象你以为在防穿透实际上系统可能在经历击穿。5.1 不同业务场景下的方案优先级建议先说结论不同业务场景的风险点和推荐方案完全不同。我直接给一张基于实际经验的对照表。业务场景主要风险首选方案辅助手段商品详情击穿、穿透互斥锁布隆过滤器本地缓存、参数校验秒杀活动击穿、雪崩逻辑过期主动预热限流、熔断用户信息穿透空值缓存参数校验布隆过滤器ID随机配置类数据雪崩随机TTL 本地缓存定时刷新、降级快照库存/余额击穿互斥锁强一致短TTL必要时直连DB这张表的逻辑是先识别业务能不能容忍旧数据再决定缓存重建方式。容忍旧数据用逻辑过期不能容忍用互斥锁。然后再看主要风险是“key不存在”还是“热点key失效”决定加布隆还是加热点探测。另外提醒一点方案不是一次选定就不动了。业务发展到不同阶段缓存数据的规模、访问模式都会变。我建议每半年重新审视一轮缓存方案核对一下命中率变化和DB压力变化。5.2 监控指标与告警阈值参考监控是早期发现问题的唯一手段。我会在项目里至少盯这五个指标缓存命中率整体命中率低于85%就该关注低于70%属于严重告警基本说明缓存设计出了问题。DB QPS与Redis QPS的比值正常比值应该远小于1比如Redis扛了10000 QPSDB只需要几十。如果Redis QPS不高但DB QPS高多半是穿透或击穿。Redis的keyspace_misses和expired_keys这两个值能直接反映缓存miss和过期量的变化趋势配合时间维度能快速定位“某个时间点大量key失效”。接口P99耗时这是最容易被平均时长大水漫过的指标。平均耗时200ms看着很美P99可能已经到3秒了。压测和告警都建议以P99和P99.9为主。热点key数量可以通过日志或网关粗统计持续监控数量变化。热点key数量陡增往往意味着大流量活动开始了需要提前检查缓存方案。这几个指标不需要一开始就全部上但至少命中率、DB QPS比值、P99这三项是必须有的。它们能覆盖穿透、击穿、雪崩三类问题的大部分早期信号。5.3 实战中踩过的几个坑最后把我踩过的几个坑分享出来每一个都对应一个线上事故或者一次压测翻车现场。坑一分布式锁误删。最早我释放锁用的是简单DEL命令结果业务线程查询DB很慢锁自动过期后其他线程拿到锁前一个线程执行完把别人的锁DEL了于是同时有两个线程在重建缓存击穿没防住还多了两倍的DB压力。改造成Lua脚本后这个问题彻底消失。坑二空值缓存和真实缓存没区分。某项目里空值占位符直接写成了空字符串读缓存时判断逻辑又简单写了if value ! null导致一段时间内空值被当真实数据返回接口数据错乱。后来把占位符统一成NULL_PLACEHOLDER并且在反序列化前单独拦截才算解决。坑三布隆过滤器只增不删误判率越来越高。项目跑了大半年布隆过滤器里堆积了大量早已下架的旧商品ID误判率从设计的1%涨到了接近10%。后来改成每季度基于DB全量数据重建一次才把误判率压回去。坑四随机TTL范围设置的太小。最初随机范围是0到60秒业务高峰期一到DB压力只是从陡峰变成了缓坡没有本质变化。后来把范围扩大到600到900秒配合本地缓存效果才真正出来。坑五压测只看平均值。某次压测Redis和DB各项指标都正常平均响应时间150ms但实际值班时接口一个接一个的告警。后来把压测结果里的P99调出来看才发现高峰期P99已经飙到2秒以上平均数是彻底被“99%的慢请求”和“1%的快请求”平均出来的假象。打那以后所有读接口的告警阈值都以P99为准。上面这些内容是我在多次线上事故和方案迭代之后整理出来的心得。如果你正在设计一套新的缓存体系我的建议是别急着把布隆过滤器、分布式锁、逻辑过期全部堆上去。先把监控搭好让数据告诉你系统正在经历的是穿透、击穿还是雪崩再针对性地加方案。等你在生产环境的告警里真正区分开这三个问题的时候你对缓存的理解才算真正到位了。

Redis缓存穿透击穿雪崩实战：故障链路与有效方案

相关推荐

三维重建的步骤-1（采集的是环绕物体均匀旋转一圈的视频）

以太网高可用方案：网络架构、IP规划与Keepalived VIP漂移实录

Claude Code插件市场搭建指南：从JSON目录到Git分发实践

更多资讯

sentry_drift鸿蒙化适配：Flutter数据库级性能追踪

VS Code 高效开发实战：从安装配置到插件调试完整指南

AI调度官真的能管好团队？从拆目标到团建的三周实测拆解

智能体技能体系设计：从提示词到可复用能力单元

GPT-4o API接入实战：认证、流式输出与工程优化全攻略

CactiEZ实战：华为、H3C、中兴交换机SNMP监控模板导入与排错

今日更新

微信云开发旅游小程序实战：LBS打卡+UGC社交全栈方案

金融AI代理平台核心拆解：从多代理协作到财报分析实战

基于大数据的智慧旅游推荐与可视化平台架构实践

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？