凌晨两点半值班手机把我从浅睡眠里拽了出来。监控平台上数据库的慢查询曲线直直地往上冲像是心电图上拉平了的直线。第一反应是缓存挂了登录服务器去看Redis的QPS正常内存占用也正常数据节点一个没宕。那问题出在哪拉出接口日志排查才发现有一批请求在持续查询一些根本不存在的商品ID每一条都精准地绕过了缓存直接砸到数据库上。这就是典型的缓存穿透。它在生产环境里的隐蔽性极高——不像缓存雪崩那样来势汹汹也不像缓存击穿那样集中在某个热key上穿透往往是一堆查无此物的请求安安静静地把数据库的资源耗干。这篇文章我想把穿透问题的解决思路完整梳理一遍从原理到落地从单点防御到组合打法把我自己踩过的坑和沉淀下来的方案一次讲清楚希望对你手头的项目有帮助。1. 缓存穿透从一次查了个不存在的东西开始先明确一个最基本的定义。缓存穿透指的是请求的数据在缓存中不存在在数据库里也不存在导致每一次请求都要穿透缓存层直接访问数据库。正常情况下一个查询流程是这样的请求进来先从Redis里查命中就直接返回没命中就去数据库查数据库里有再把数据回填到缓存下一次请求就能命中。这套流程之所以高效是因为绝大多数请求会在缓存层被截住只有少量冷数据或缓存过期的请求才需要回源数据库。但穿透不一样。如果一个请求查的是个不存在的key——比如用户传了一个不存在的商品ID或者一个已经被系统删除的数据ID——那么缓存永远不可能命中数据库也永远查不到缓存自然也没有机会回填。结果是只要有人一直发起这类请求数据库就会被持续打到。在实际项目里穿透的来源通常有两种业务自身的场景用户输入了错误ID、前端数据异常、爬虫遍历ID、系统间同步数据出现脏数据。恶意攻击有人故意构造大量不存在的ID发起高频请求目的是耗尽数据库连接让正常业务不可用。第二种尤其危险。因为正常业务场景下的穿透数量往往有限而恶意攻击可以在极短时间内发起几十万甚至上百万次无效查询直接拖垮数据库。我在某电商平台的售后系统里就见过一次典型的攻击攻击者拿着一段连续但不存在的订单号用脚本每分钟打几千次请求订单查询接口的响应时间从50毫秒被拉高到5秒以上。穿透和另外两个缓存问题经常被混在一起我在这里先把边界划清楚问题触发场景本质缓存穿透缓存和数据库都没有该数据查询根本不存在的数据缓存击穿某个热key突然过期大量请求同时回源热点key失效瞬间的并发冲击缓存雪崩大量key同一时间过期或缓存节点故障大规模缓存失效从防御思路上说穿透要解决的是让无效请求别到达数据库击穿要解决的是让热key失效瞬间只有一个线程回源雪崩要解决的是分散失效时间、保证缓存高可用。三者可以同时存在也可以互相叠加后面我会专门讲穿透和击穿纠缠时的处理。2. 第一道防线参数校验的价值比想象中大很多团队一说到解决缓存穿透第一个想到的就是上布隆过滤器或者缓存空值。但我觉得最便宜、最有效、最容易被忽略的防线其实是入口参数校验。我在复盘上面提到的那次订单接口故障时发现攻击者用的订单号根本不符合系统规则——正常订单号是18位数字他发的是一串20多位包含字母的字符串。如果接口在进入缓存逻辑之前就做一轮基础校验这些请求根本走不到Redis。参数校验的核心原则很简单业务规则上不可能存在的数据直接返回不合法不进入缓存查询链路。常见的校验手段包括格式校验ID是否为空、长度是否符合规则、是否为纯数字、是否在合法范围内。枚举校验类型字段是否在业务定义的枚举值内比如订单状态、商品渠道。范围校验数值型ID是否小于等于0分页参数是否越界。代码上的实现也不复杂。以最常见的商品查询为例public ProductInfo queryProduct(String productId) { // 第一层基础参数校验 if (productId null || productId.length() ! 18) { return null; } if (!StringUtils.isNumeric(productId)) { return null; } long id Long.parseLong(productId); if (id 0) { return null; } // 再走缓存查询逻辑 // ... }你可能觉得这太基础了但根据我的经验**大量线上穿透事故的起点就是一个没做参数校验的老接口。**比如早期的商品详情接口入参是用户直接传的ID没有任何约束后来加了个布隆过滤器才堵上。如果一开始就在网关层把参数校验做扎实很多后续方案根本不需要上。还有一个容易被忽略的细节参数校验不只是防穿透它对下游所有环节都有保护作用。一个非法的超大ID如果进入Redis会增加一次不必要的网络IO进入数据库会多一次无效SQL执行万一数据库对这类查询没有合适的索引还可能引发慢查询。所以我的建议是**参数校验放在最前面多层逻辑共用。**如果项目有网关层在网关层做一次基础校验在业务层再做一次业务规则校验。宁可重复校验也不要留缺口。3. 缓存空值朴素方案的正确打开方式参数校验能挡住一部分明显不合法的情况但挡不住合法规则的ID业务上确实不存在。比如用户手滑输了一个格式正确、范围合理、但没有任何商品对应的ID这种请求还是会穿透到数据库。对付这类请求最直接的手段就是缓存空值当数据库查出结果为空时把空这个结果本身也缓存起来并设置一个较短的过期时间。后续同样的请求再来命中的就是这个空值缓存不会再去数据库查。核心逻辑用一个简单的流程描述1. 查询缓存 2. 命中 - 返回缓存值可能是空值 3. 未命中 - 查询数据库 4. 数据库查到数据 - 回填缓存设置正常TTL返回数据 5. 数据库没查到 - 回填空值到缓存设置短TTL返回空Redis侧的实现很简单代码类似def query_product(product_id): # 先查缓存 cache_key fproduct:detail:{product_id} value redis.get(cache_key) if value is not None: # 命中了包括空值 if value EMPTY_FLAG: return None return deserialize(value) # 缓存未命中回源数据库 product db.query_product(product_id) if product is None: # 数据库也没有缓存空值TTL设置短一点 redis.set(cache_key, EMPTY_FLAG, ex60) return None # 正常数据正常TTL redis.set(cache_key, serialize(product), ex300) return product这里有几个参数和细节我强烈建议你按生产标准来设计。3.1 空值TTL怎么定空值缓存的过期时间不宜太长也不宜太短。太短了起不到保护作用——比如设成5秒攻击者每秒发起10个不同ID的请求每个ID的缓存5秒过期后都有一次穿透机会数据库还是会被打到太长了又可能导致一个已恢复的数据在较长时间内被误认为不存在。我常用的经验值是1到5分钟。对于那些业务上极少出现存在性变化的场景比如订单号、已归档的日志ID可以设到10分钟对于商品详情这种实时性较强的场景1分钟就够。原则是空值TTL 业务能够容忍的短暂不可见时间。3.2 空值必须和正常值区分这道坑我踩过。之前有同事实现缓存空值方案时直接在缓存里存了一个空字符串没有做标记。结果业务方在读取缓存时把空字符串反序列化后得到了一个默认对象直接返回给了前端用户看到的是一个不存在的商品被当成了空壳商品造成了一堆数据异常。正确做法是给空值设一个特殊的占位标记和正常缓存值在结构上区分开。比如统一加一个字段{ is_null: true, data: null }或者用一个业务上不可能出现的字符串常量比如__NULL__。读取的时候先判断是否为空值标记再决定是否返回空。另外一个习惯是给空值缓存key加上特殊前缀比如empty:product:detail:{id}这样在监控Redis内存和统计key数量时可以方便地识别出空值缓存有多少也方便清理。3.3 内存膨胀问题这是缓存空值方案的硬伤。一张表里如果有100万个不存在的ID被查过Redis里就会多出100万个空值key。每个key就算只占几十字节100万个也是几十MB到上百MB的量。如果攻击者故意生成大量随机ID这个量级还会继续增长。要有总量控制机制。我见过比较靠谱的做法是给空值缓存设置一个最大key数量上限比如预估支撑100万个空key够用超出上限就触发清理。对已有的空值key做抽样扫描把长期没被访问的提前删除。在入口做单IP/单用户的访问频率控制从源头减少空值缓存的新增速率。最后再提醒一下缓存空值不解决同一个key的高并发同时回源问题。比如一个不存在的ID同一秒内来了1000个请求第一个请求还没执行完查库回填空值的流程剩余999个请求因为没命中缓存还是会全部打到数据库。这就是穿透和击穿的叠加场景我会在第5节专门展开。4. 布隆过滤器把不存在变成免查清单缓存空值的特点是查到了没有我才缓存没有。而布隆过滤器更进一步它的思路是在查询之前就告诉你这个key大概率不存在根本不用进缓存。布隆过滤器Bloom Filter是一个很经典的数据结构它的核心是用一个很长的二进制位数组和几个哈希函数来表示一个集合的成员关系。判断一个元素是否在集合里把它经过多个哈希函数映射到几个位如果这些位都是1就说它可能存在只要有一个位是0就确定必然不存在。这个设计带来了两个特性缺一不可绝不漏判如果数据真的在集合里查询时它对应的位一定都是1所以布隆过滤器永远不会把一个存在的数据误判为不存在。可能有误判因为不同元素可能映射到相同的位当位数组里1越来越多时一个不在集合里的元素也可能恰好命中所有位被误判为可能存在。对缓存穿透场景来说这两个特性刚刚好。我们要拦截的是确定不存在的ID布隆过滤器能保证不拦截真实存在的ID至于它把少量不存在的ID误判成可能存在也无所谓因为接下来的缓存和数据库查询环节会继续兜底。4.1 内存开销怎么算很多人担心布隆过滤器会占用大量内存其实恰恰相反它的内存效率非常高。位数组大小和预期元素数量、可容忍的误判率之间存在一个公式位数组大小 m -n × ln(p) / (ln2)²其中 n 是预期元素数量p 是误判率。举个例子。假设你的商品表里有1000万个ID你希望误判率控制在1%那么需要的位数组大小是m -10,000,000 × ln(0.01) / (ln2)² ≈ 95,850,000 bit ≈11.4 MB你没看错给1000万个ID做一层存在性过滤只需要大约12MB内存。哈希函数的数量按公式计算k (m / n) × ln2 ≈ 6.64取7也就是说每个元素映射到7个位就够了。这在Redis里就是个小case。计算过程我简化处理了实际项目中你可以直接用现成工具算。Java里有Google的Guava库BloomFilter类可以直接创建BloomFilterLong filter BloomFilter.create( Funnels.longFunnel(), 10_000_000, // 预期元素量 0.01); // 期望误判率1%Redis从4.0开始提供了布隆过滤器模块可以用BF.ADD、BF.EXISTS命令直接操作非常方便不需要自己在业务代码里维护位数组。4.2 数据初始化与更新布隆过滤器在工程落地时最让人头疼的不是数据结构本身而是和业务数据的同步。初始化阶段需要把当前数据库里所有有效ID都加载到过滤器里。1000万个ID的加载通常不是实时逐个加的而是批量刷入或者直接用离线任务预热。这一步的时序要注意如果过滤器还没加载完就上线会误杀真实存在的ID导致业务异常。更新阶段每新增一个数据就要往过滤器里加一个ID。删除数据时问题就来了——标准布隆过滤器不支持删除。因为一个位可能被多个元素映射你不能把一个元素对应的位清0否则可能把其他元素也清掉了。解决思路有两个后面详述。因此实际项目中布隆过滤器往往只在判断存在性这个环节使用删除后的ID在过滤器里仍然占位影响的只是极少数误判查询无害。4.3 误判率的代价布隆过滤器的误判不是零成本的。当误判发生时一个事实上不存在的ID会被放进缓存查询链路走一遍缓存和数据库。但因为这类请求数量通常不多数据库完全扛得住。我见过有的团队因为担心误判把布隆过滤器误判率设成0.001%结果内存暴增性能也下降。我的建议是1%甚至5%的误判率对穿透防护来说完全够用没必要追求极致。过滤器的价值是挡掉99%以上的无效请求剩下的1%交给缓存空值去兜底形成互补。4.4 和缓存空值的取舍这里说点实际经验。布隆过滤器和缓存空值不是二选一而是根据场景分主次如果业务中的ID集合比较稳定不会频繁增删且总量可预期优先用布隆过滤器做前置拦截效果最好内存最省。如果ID集合变化很快比如每天新增大量短时效数据布隆过滤器的更新链路会变得复杂这时候缓存空值更灵活不用维护全量ID集合只要在查不到时回填空值就行。实际操作里我所在团队的做法是**网关层放布隆过滤器挡恶意穿透业务缓存层放空值缓存挡正常误判。**两层各干各的互不冲突。对稳定性要求极高的核心链路会同时上。布隆过滤器档住绝大多数无效请求空值缓存顶住那1%的漏网请求数据库压力趋近于零。5. 穿透和击穿纠缠时互斥锁怎么接前面提到一个容易被忽视的场景同一个不存在的key在同一时间窗口内被大量请求同时访问。这种情况下缓存空值的第一次回填其实还是会让所有请求同时打到数据库。举个具体例子。攻击者构造了一个productId123456789的请求这个ID在缓存里没有值在数据库里也不存在。缓存空值方案下第一个请求发现缓存未命中去数据库查没查到回填空值整个过程可能耗时50毫秒。就在这50毫秒里如果这个ID的请求量是每秒10000次那前几千个请求都会处在缓存未命中状态全部并发打向数据库。这一波冲击数据库很可能顶不住。这个场景的实质是**一个不存在的key在尚未缓存空值的窗口期承受了高并发的回源压力。**它和缓存击穿在表现上非常像区别在于击穿的是真实存在但刚好过期的热key这里击穿的是本就不存在的key。解决思路也类似在回源数据库查数据之前保证同一个key只有一个线程在查其他线程等待结果。这一段我直接给一个通用实现方案。Java里可以用Redisson的分布式锁也可以用Guava的本地锁核心逻辑是一致的public ProductInfo queryProduct(String productId) { // 先查缓存 String cacheKey product:detail: productId; Object value redis.get(cacheKey); if (value ! null) { return deserialize(value); } // 缓存未命中尝试获取锁 String lockKey lock:product:detail: productId; RLock lock redisson.getLock(lockKey); boolean locked false; try { // 尝试获取锁等待时间3秒 locked lock.tryLock(3, TimeUnit.SECONDS); if (locked) { // 拿到锁后再次查缓存防止第一个线程已经回填 value redis.get(cacheKey); if (value ! null) { return deserialize(value); } // 真正回源数据库 ProductInfo product db.queryProduct(productId); if (product null) { redis.set(cacheKey, EMPTY_FLAG, 60); } else { redis.set(cacheKey, serialize(product), 300); } return product; } else { // 其他线程拿不到锁短暂等待后直接查缓存 Thread.sleep(50); value redis.get(cacheKey); if (value ! null) { return deserialize(value); } return null; } } finally { if (locked) { lock.unlock(); } } }这段代码有两个细节值得注意。第一个是拿到锁之后必须先查一次缓存这就是经典的双重检查锁定。因为抢锁失败的线程可能已经先把缓存填好了拿到锁的线程如果直接查库就白白浪费一次回源。第二个是拿锁失败的线程不要无限等待。我给的方案是睡50毫秒再查一次缓存还是没查到就返回空。实际生产中等待时间可以根据业务对一致性的要求调整。有的团队选择直接自旋查缓存直到超时有的团队选择直接返回正在查询中的提示——具体取决于你的业务能不能接受短暂的空结果。有了互斥锁同一个key在高并发下的回源次数就被压缩到了1次。但如果空值缓存到期了下一次请求又会重复这个过程。所以对于持续被攻击的key建议同时把这个key加入短时黑名单在黑名单有效期内直接拒绝查询或者延长它的空值TTL。6. 生产环境的组合防御我习惯的分层结构解决缓存穿透没有一个方案是银弹。参数校验挡不住合法格式的不存在ID缓存空值挡不住首次回源的并发布隆过滤器挡不住误判。真正稳妥的做法是分层防御每一层拦截一部分风险最后落到数据库的请求趋近于零。我在团队里常用的分层结构是这样的6.1 第一层入口限流与参数校验网关层做两件事。第一基础参数校验把明显非法的请求直接返回第二对单IP、单用户、单接口维度做访问速率控制阻断高频恶意请求。限流本身不是防穿透的核心但它能有效压制穿透攻击的请求量级。从根上看穿透攻击和普通的高频刷接口在威胁模型上有重叠只要请求到达不了业务层后面的缓存和数据库就安全。6.2 第二层布隆过滤器拦截不存在的key对核心查询接口在进入缓存查询之前先查布隆过滤器。如果过滤器说不存在直接返回空结果不碰缓存不碰数据库。这里是拦截效率最高的一层能挡掉绝大多数无效请求。千万不要把布隆过滤器放在Redis缓存之后——那样无效请求仍然会打到Redis增加了不必要的IO压力布隆过滤器的价值就缩水了。6.3 第三层缓存空值兜底布隆过滤器有误判缓存空值负责把这些漏网的不存在ID变成短期可命中的key。当数据库返回空时写入短TTL空值保护后续重复请求。这层还要配合互斥锁确保同一个key在同一时间窗口内只有一个线程回源避免首次回填瞬间的并发击穿。6.4 第四层数据库查询兜底与降级走到这一步的请求已经是少数。数据库侧还需要加两个保险一是所有查询必须走索引避免全表扫描放大压力二是数据库连接池设置最大上限超出的请求直接排队或快速失败而不是无限堆积。如果缓存和数据库同时出现异常比如Redis集群不可用这时候还要有熔断降级机制——比如直接返回一个精简版的页面数据或者提示用户稍后重试而不是让请求无限重试把数据库拖死。6.5 监控指标要盯哪些方案上线后监控比方案本身更重要。我建议至少要盯这几个指标DB QPS回源数据库的请求速率这是衡量穿透防御效果最直接的指标。缓存命中率命中率突然下降往往意味着有大量新key涌入或空值缓存被刷爆。空值缓存key数量监控空值key的增长率如果短期内暴增说明有人在大量扫描不存在的ID。布隆过滤器误判率虽然很难线上实时统计但可以通过拦截后仍然命中数据库空查询的比例来估算。我习惯给DB QPS设置双层告警超过日常峰值30%触发黄色告警超过100%触发红色告警。空值key的数量增长也设一个速率阈值比如每分钟新增超过1万个就告警。6.6 一个从现实项目里沉淀的组合案例之前给某电商的售后订单查询接口做过一次完整改造。订单表大概2000万条数据每天正常的查询量是500万次其中约3%是无效订单号查询——有用户输入的有爬虫扫描的。改造前数据库每天因为无效查询产生的压力占到总QPS的15%左右高峰时段偶尔抖动。改造方案是分两步走。第一步在入口加订单号格式校验18位纯数字暴力过滤掉了一部分非标输入。第二步用Redis的布隆过滤器缓存所有有效订单号在查询入口前置拦截同时对误判的请求做缓存空值兜底空值TTL设为5分钟。改造后DB QPS下降了12个百分点高峰时段数据库稳定了很多订单查询接口的P99响应时间从400毫秒降到120毫秒。这个案例里布隆过滤器和缓存空值同时存在各管一段布隆过滤器拦截大量无效请求缓存空值吸收误判和首次穿透。7. 几个容易翻车的细节我替你们先踩一遍方案原理说完了。但真正落到工程上总有些细节会把你绊一跤。我捡几个亲身踩过的坑按从高到低的翻车概率说一说。7.1 空值缓存是否污染了业务数据我见过一个团队把空值缓存和正常缓存放在同一个key空间里结果下游做数据统计时把空值key的个数也算进了商品数量数据报表直接失真。这个其实很好规避就是之前说的**空值缓存用单独的key前缀并且跟正常缓存域名分开。**这样既能统计监控又方便一键清理。7.2 布隆过滤器数据加载的时序坑重新上线布隆过滤器的时候如果数据库里已有存量数据必须先做全量加载加载完成后再切流。你要是先切流再加载真实存在的ID在过滤器里还是空的就会被误杀。我自己遇到过因为加载过程用了异步任务前端业务已经跑起来了导致新上线的所有商品详情都返回不存在排查了半小时才发现是过滤器冷启动问题。7.3 布隆过滤器删除怎么处理前面说了标准布隆过滤器不支持删除那业务上删了一个商品之后过滤器里的对应位怎么办我的建议是不处理。这个位会继续留在那里因为其他ID也可能映射到这个位不能为了它单独清位。它的影响只是让过滤器对某些ID的不存在判断失效但这些ID其实已经不存在了被缓存空值兜底后没有任何危害。如果业务上确实频繁删除且量很大可以考虑定期重建过滤器比如每周凌晨从数据库全量重建一次把无效的位清掉。7.4 不要把过滤器用于小集合如果集合只有几千个元素布隆过滤器的内存优势体现不出来而且初始化、更新链路的复杂度会超过它带来的收益。这种情况下用普通缓存或者直接让缓存空值去兜反而更简单可靠。我的经验是预期元素量在百万级别以上才值得上布隆过滤器。7.5 空值TTL和业务一致性给空值设置了5分钟TTL意味着如果一个数据在5分钟之内被创建出来在这段时间内它的查询结果仍然是不存在。这在有些业务里不可接受。比如秒杀系统商品是在活动开始前几分钟才创建并上线的如果空值TTL设得比创建时间还长就会造成商品已创建但前端还是查不到的体验问题。解决方案是创建数据时主动删除对应的空值缓存key让下一次请求立即回源数据库拿到新数据。7.6 测试用例要覆盖穿透路径很多团队在测试缓存逻辑时只测了缓存命中和缓存未命中后回源成功两条路径恰恰没测缓存未命中后回源为空这条路径。结果空值缓存逻辑上线后第一个不存在的ID就触发了NPE或者序列化异常。写测试时一定要把查询不存在的ID作为一条独立的用例覆盖到而且要模拟并发场景验证互斥锁是否真的只回源了一次。我在实际项目里发现**这六条中的前三条几乎每个新接手缓存模块的同事都会踩一遍。**你提前绕过这些坑后续的线上问题至少能少一半。遇到缓存穿透类告警时按这套思路排查和加固基本都能在半小时内定位到根因并拿出方案。最后说个小技巧。如果你不确定自己的方案对空值和不存在的边界处理是否完善可以在上线后做一次小范围的流量染色测试——故意发一批格式合格、内容不存在的请求观察数据库回源量是否如预期趋近于零。这个动作成本很低但对验证整体链路的作用非常大。