先从一段我亲身经历的线上事故说起。某个周二下午监控面板上数据库连接数从 200 一路跳到 2000Redis 命中率从 99% 肉眼可见地往下掉。第一反应是缓存挂了但 Redis 明明还活着数据库那边已经满屏慢查询连接池马上要被打满。排查到最后发现有人用一批不存在的商品 ID 在刷接口每次请求都是缓存没有、数据库也没有最后只能直接返回空。这个场景就是经典的 Redis 缓存穿透。说实话缓存穿透、缓存击穿、缓存雪崩这三件事很多同学面试前背得滚瓜烂熟但真到了线上遇到告警反而分不清自己遇到的是哪一种。这篇文章我不打算按教科书的方式念定义而是想还原一下这三个问题在真实业务里的表现、排查链路、以及我实际用过的解决方案。如果你是正在维护偏读多写少、请求量上百万的系统或者正准备从零把缓存治理做到位这篇应该能帮你省不少时间。1. 先看一条旁路缓存链路再谈三个“事故现场”1.1 旁路缓存的标准姿势使用 Redis 作为缓存最常见的架构是旁路缓存模式。请求进来先查 Redis命中直接返回没命中就去查询数据库拿到结果后把数据回填到 Redis再返回给调用方。这样的好处是 Redis 只承担“缓存”职责数据库是唯一的数据源逻辑简单也不容易出现缓存和数据库之间的强一致性问题。这里两个角色各管一边Redis 挡掉大部分重复请求数据库负责真正捞数据。这个架构本身没有问题问题出在“没命中”的时候。当请求量足够大一个“没命中”的请求落到数据库数据库还能扛但一万个、十万个“没命中”同时落下去数据库就很容易成为单点瓶颈。1.2 缓存未命中的不止一种走向同样是“缓存没命中”背后其实有三条完全不同的路径穿透key 本身就不存在数据库里也没有。缓存和数据库全部落空每次请求都在白忙活。击穿key 存在但这个热点 key 恰好到了过期时间。缓存没了数据库里有一瞬间所有并发请求都冲去数据库捞。雪崩大量 key 集中在同一时刻失效或者 Redis 节点直接不可用。整个缓存层失效数据库接住全部流量。这三条路径看起来都是“缓存没数据”但是成因不同、影响范围不同、修复手段也完全不同。如果分不清去线上改配置基本就是拆了东墙补西墙。我用一个表格快速画一下边界问题本质影响范围典型触发场景缓存穿透数据不存在缓存永远没数据单个请求/持续高频恶意刷不存在的 ID、漏填缓存空值缓存击穿单个热点 key 过期单 key 大并发秒杀商品、热帖、热点榜单缓存雪崩批量 key 过期或缓存层不可用全局性批量预热、TTL 统一、Redis 宕机1.3 为什么面试总爱问这三兄弟其实不只是面试题好看而是每一个上规模的系统都很难绕开这些问题。我在不同团队做过缓存治理凡是流量上到一定量级几乎都会在某个时段遇到其中一种。能不能在第一时间判断出是哪一个问题决定了你是能把故障摁在五分钟内还是要加班到凌晨两点。所以了解三大问题的本质比死记几条解决方案值钱得多。2. 缓存穿透数据库在替一个不存在的 key 加班2.1 穿透的典型特征穿透的核心特征是“查了个不存在的东西”。正常业务里用户查一个已经被删除的商品或者攻击者故意构造大量不存在的 ID缓存里没有任何记录数据库查询结果为空也没有人把空结果写回缓存。于是每一次请求都走完整的“Redis 未命中 - 数据库查询 - 返回空”链路。这个问题的可怕之处在于单个请求的代价很低但请求量一旦放大数据库就变成了单纯替不存在的 key 做无意义的查询。我曾经见过一个外包系统的接口因为没有对参数做任何约束被人用脚本按 ID 递增去扫描数据库直接被打到连接池耗尽业务全部接口跟着挂掉。2.2 方案一空值缓存别让数据库反复回答“没有”穿透最直接的解法就是把“查不到”这个结果也缓存起来。也就是当数据库查询结果为空时不是直接返回而是写入一个特定标记到 Redis设置一个相对短的 TTL例如 60 秒。后续同样的 key 再进来直接命中这个空值缓存不会再落到数据库。一个简单的伪代码示例Object value redis.get(key); if (value ! null) { return value; } // 这里才走数据库 Object dbValue db.get(key); if (dbValue null) { // 把空值也缓存起来TTL 要短 redis.set(key, EMPTY, 60); return null; } redis.set(key, dbValue, 300); return dbValue;这里有几个实操上的坑我踩过空值 TTL 不能太长。如果这个 key 很快被写入真实数据用户看到的还是空值缓存导致数据一致性延迟。建议控制在几十秒到几分钟之间。空值缓存也不能完全没有。如果这个空 key 是持续被高频访问的每次过期后还是会穿透到数据库。所以空值缓存 TTL 可以短但要比请求频率更合理。遇到 List、Hash 这类结构空值可以缓存为空集合避免客户端在 null 和空集合之间做额外判断。2.3 方案二布隆过滤器在缓存之前先挡一轮空值缓存解决的是“查过一次”的不存在 key但如果攻击者每次都换新 ID空值缓存形同虚设这时候要考虑布隆过滤器。布隆过滤器的原理不复杂一个位数组加上若干哈希函数。写入某个 key 时对 key 算 k 次哈希把位数组对应位置置为 1判断某个 key 是否存在时同样算 k 次哈希看这些位是否都是 1。只要有一个位是 0就能确定这个 key 一定不存在全为 1只能说“可能存在”。它对“不存在”的判断是绝对的对“存在”的判断存在一定误判率但不漏判。这就非常适合放在缓存查询之前先判断 key 是否可能存在如果连可能存在都谈不上直接返回数据库连一次查询都不用做。接入的时候大概是这样// 初始化阶段把全量存在的 key 灌进布隆过滤器 for (String id : allIds) { bloomFilter.put(id); } public Object get(String key) { // 布隆过滤器先判断 if (!bloomFilter.mightContain(key)) { return null; } // 之后才走缓存和数据库 Object value redis.get(key); if (value null) { Object dbValue db.get(key); // ... 正常回源逻辑 } return value; }落地的时候有个容易忽略的问题Redis 本身没有内置布隆过滤器你需要用 RedisBloom 模块提供 BF.ADD、BF.EXISTS 命令或者直接用位图SETBIT/GETBIT自己实现一套。我建议优先用 RedisBloom社区方案成熟也避免自己实现哈希函数时踩各种数学坑。至于内存估算可以用公式 m -n * ln(p) / (ln 2)^2其中 n 是预估 key 数量p 是期望的误判率。100 万条数据误判率 1%大概需要 1.2MB 的位数组这个成本完全可接受。这里有一个很重要的注意点布隆过滤器不适合频繁增删 key 的场景因为删除一个 key 时你不能简单把对应位还原为 0那会影响其他 key 的判断。所以如果业务上 key 集合变化非常快你需要考虑定期重建过滤器或者用带删除能力的 Cuckoo Filter不过那又是一个新话题了。2.4 方案三入口校验这些流量压根不该进来有些穿透流量其实在入口就能拦下来。比如商品 ID 有固定格式和范围用户 ID 有状态提前做参数校验把不合法、越界、明显是脚本构造的参数直接拒绝数据库连压力都感知不到。这类校验虽然看起来很简单但经常被忽略。我见过不少项目在网关层只做了鉴权没做参数合法性校验结果一个公开的列表接口被循环扫 ID硬生生扫出一个穿透事故。入口校验应该是成本最低的第一道防线但不是唯一的防线因为总会有一些合法但不存在的 ID 漏过去。2.5 穿透场景的实际注意事项总结一下穿透治理的经验教训空值缓存解决的是“同一个 key 反复查询”它能把重复穿透拦住布隆过滤器解决的是“不断换 key 的扫描”它能把不存在的 key 直接挡在缓存链路之外参数校验解决的是“明显不合法的请求”它负责降低进入系统的垃圾流量三个手段可以叠加但没必要一开始就全上先看监控曲线再决定在哪一层做加固。3. 缓存击穿热点 key 失效的那一秒流量全压向数据库3.1 击穿为什么比穿透更隐蔽如果说穿透是“查了个不存在的东西”击穿就是“查了个存在但恰好过期了的热点东西”。正常情况下热点 key 的请求几乎全部命中缓存数据库很轻松。但 key 到了过期时间缓存里那一瞬间没有数据大量并发请求同时发现未命中一起冲到数据库数据库在一秒内被灌进平时几个小时的请求量。击穿比穿透更隐蔽是因为它的窗口非常短。穿透可以通过持续请求观察到命中率持续走低击穿可能就发生在几秒钟之内等你打开监控面板的时候Redis 已经回填了新的缓存数据库也缓过来了现场已经没了只剩下数据库中残留的慢查询。典型场景秒杀商品详情页、热榜 Top 1 的帖子、直播间的某个爆款商品。这些 key 的并发量足够高一旦失效就可以造成 QPS 尖峰。3.2 互斥锁只让一个请求回源重建击穿第一反应是加锁。让缓存失效后只允许一个线程去数据库查询并重建缓存其他线程等待缓存重建完成或者直接快速返回旧值。Redis 在做这种分布式锁时很顺手用一条 SET 带上 NX 和 EX 即可String token UUID.randomUUID().toString(); Object value redis.get(key); if (value ! null) { return value; } // 尝试加锁只允许一个线程回源 if (redis.set(lock: key, token, NX, EX, 10)) { try { // 拿到锁后要二次检查缓存 value redis.get(key); if (value ! null) { return value; } Object dbValue db.get(key); redis.set(key, dbValue, 300); return dbValue; } finally { // 只删除自己加的锁 String lockValue redis.get(lock: key); if (token.equals(lockValue)) { redis.del(lock: key); } } } // 没抢到锁短暂等待后重试 sleep(50); return get(key);这里有三个细节必须注意拿到锁之后要二次检查缓存避免多线程在锁上排队结果第一个线程已经重建完缓存后面的线程又去数据库跑一遍。锁要设置过期时间防止自身宕机或 GC 停顿导致锁永久不释放形成死锁。释放锁时要校验是不是自己的锁否则可能误删别的线程刚创建的锁。以前很多人会把锁这块做重直接引入 Redisson 那套带看门狗的分布式锁。但如果你只想解决“热点 key 回源”这一个问题一条 SET NX 就够没必要为了一个缓存重建引入全套分布式锁体系。3.3 逻辑过期缓存永不过期数据异步刷新互斥锁最大的缺点是如果回源重建非常慢其他线程都在自旋等待虽然不会压爆数据库但接口 RT 会很难看。更优的实践是“逻辑过期”。思路很简单key 不设置物理 TTLvalue 里存一份数据本身和逻辑过期时间。读取的时候比较当前时间与逻辑过期时间如果还没过期正常返回如果已经过期先把旧数据返回给调用方同时提交一个异步任务去数据库查询并更新缓存。// 缓存结构data 逻辑过期时间 redis.set(key, JSON.stringify(new CacheEntry(dbValue, now 600))); public Object get(String key) { String cache redis.get(key); if (cache null) { // 这里还是要配合互斥锁或布隆过滤器处理 return db.get(key); } CacheEntry entry JSON.parse(cache); if (entry.expireAt now) { return entry.data; } // 逻辑过期先返回旧数据异步重建 asyncRefresh(key); return entry.data; }逻辑过期方案的关键收获是缓存永远在读请求永远不会打到数据库上去。代价是数据会有短暂的不一致大促场景下这种短暂陈旧往往是可接受的但对一致性要求高的业务就不太适合。异步刷新这里也要注意如果并发很高可能出现大量异步任务同时回源。最简单的方式是在异步刷新前也尝试加一次互斥锁只让一个任务真正执行数据库查询其他任务直接丢弃。3.4 击穿方案的选型建议我的取舍标准是这样的如果回源很快简单 SQL 加一次查询耗时在几十毫秒内互斥锁就够了实现简单数据一致性好如果回源很慢涉及远程调用、复杂计算耗时几百毫秒甚至秒级优先逻辑过期不要让请求在线等待如果业务对一致性要求极高同时回源又快那还是互斥锁更稳。大部分互联网场景秒杀、热榜这种热点 key回源往往很快我实际用得最多的是互斥锁。逻辑过期更多地是用在“查一次很贵”的复杂聚合场景。4. 缓存雪崩批量过期和 Redis 宕机带来的连锁反应4.1 第一类雪崩大量 key 同时过期的现场雪崩最典型的一个形态是“缓存里一大片 key 在同一时刻集体失效”。这个现象的制造过程通常是这样的系统上线的时候做了一次缓存预热把一批数据循环写入所有 key 用了同一个 TTL。等到这批 key 同时过期原本被缓存挡掉的流量在下一个时刻全部涌向数据库。数据库可能在几分钟内就被打挂随后大量超时请求堆积进程反复重试最终形成连锁反应。这跟击穿的区别在于范围。击穿是一个 key 的并发问题雪崩是一批 key 的并发问题。一个 key 一秒内几百个请求打向数据库数据库也许能扛一百个 key 同时这么来大概率没人扛得住。4.2 应对策略让过期时间“错峰”第一类雪崩的解决思路其实很朴素别让所有 key 在同一时刻过期。业界标准做法是在基础 TTL 上加上一个随机值。int baseTtl 600; int ttl baseTtl random.nextInt(300); redis.set(key, value, ttl);这个随机值看着简单但非常有效。它把“集体过期”变成“分批过期”每个 key 过期的时刻错开数据库在同一时间收到的回源请求就被摊薄了。另外一个容易忽略的点是缓存预热。启动时批量写入缓存如果不做任何错峰所有 key 几乎同时写进去也就意味着它们也会几乎同时过期。所以预热的时候同样要按批次分散时间或者每批使用不同的 TTL 基准。4.3 第二类雪崩Redis 节点不可用比大量 key 过期更严重的是整个 Redis 实例不可用。比如单个 Redis 节点宕机主从切换瞬间缓存层的读取全部失败流量直接落到数据库如果此时数据库扛不住就会引发第二轮故障业务重试、消费者堆积、连接池耗尽。这里我要专门说一下很多人听到 Redis 高可用就想到主从、哨兵、集群这方向没错但有个容易被忽略的细节高可用只能减少宕机时间不能消除宕机瞬间的缓存穿透窗口。主从切换的几秒钟里缓存查询是会失败的你必须搞清楚应用层在这几秒钟怎么处理。如果应用把缓存查询失败当成“请求失败直接报错”那问题不大只是这一小部分请求失败了但如果应用把缓存查询失败当成“缓存未命中”去查数据库那数据库就会在几秒钟内收到大量回源请求同样有风险。所以异常处理和降级策略要提前定义。4.4 高可用架构与持久化兜底在架构层面主从加哨兵是单实例高可用的基础玩法哨兵负责监控和自动切换Redis Cluster 则更适合数据量大、并发高的场景分片加副本可以同时解决容量和可用性问题。持久化在这里的作用容易被低估。Redis 宕机重启后如果没有持久化内存里全空缓存层等于冷启动大量请求直接打向数据库这时候等于人为制造了一次雪崩。开启 RDB 做定期快照、AOF 做操作日志重启后可以尽快恢复大部分缓存数据把冷启动的冲击降到最低。这也是很多团队把“持久化机制到底要不要开”这个题聊得很深的原因。持久化和性能是有取舍的。高写入场景下 AOF 的同步策略要权衡但为了缓存层重启不冷场我通常建议至少开启 RDB 快照再根据数据重要性决定 AOF 的同步级别。4.5 多级缓存和降级让系统在极端情况还能喘气不管是批量过期还是 Redis 宕机真正兜底的方案是多级缓存加降级策略。多级缓存常见的做法是JVM 内本地缓存比如 Caffeine做第一级Redis 做第二级数据库做最后一级。热点 key 可以在本地缓存里放一份设置一个比较短的 TTL比如 30 秒。Redis 不可用的时候本地缓存还能挡住相当一部分读请求。降级策略则要定义清楚缓存不可用时是直接让请求走数据库还是返回一个降级页面/默认数据。我的建议是给核心链路设置一个“允许穿透到数据库的比例”比如正常情况下 5% 的流量可以落到数据库剩下的直接走降级当数据库压力也接近门槛时这个比例再往下调甚至完全阻断回源。多级缓存也不是万能的本地缓存有数据一致性问题。每次写入 Redis 时可以考虑同步更新本地缓存或者接受最长几十秒的不一致这个需要业务侧评估。但是用多级缓存对抗雪崩方向肯定是对的。5. 遇到线上告警如何反向判断是穿透、击穿还是雪崩5.1 Redis 侧能看到的证据接到告警以后的第一个动作我永远是打开缓存命中率。用 Redis 的 INFO stats 命令看两个数字keyspace_hits 和 keyspace_misses。miss 数在短时间内突然增加第一步就跑不掉穿透冲击。平时我习惯在 Another Redis Desktop Manager 这种可视化客户端里看这几个指标的曲线感觉比命令行直观命中率从 99% 掉到 80%伴随数据库慢查询上升基本可以断定有不正常流量在穿透缓存层。再配合 Redis 的 slowlog 和 monitor能进一步看清是哪些 key 在被频繁访问。不过 monitor 在高流量下会拖累 Redis 性能线上最好只在短时间内使用或干脆不用更多依赖业务日志。5.2 数据库侧的慢查询和 QPS 曲线数据库侧的证据更直观。如果数据库 QPS 曲线出现一个非常窄的尖峰过了就恢复正常大概率是击穿某个热点 key 过期了重建完成之后流量又回到缓存。如果 QPS 曲线持续走高迟迟不回落更像穿透不断有不存在的 key 在打数据库。如果数据库 QPS 瞬间打满、随后 Redis 侧也出现主从切换日志或节点重启记录那基本就是雪崩。这时候去查缓存层高可用状态而不是盯着单个 key 分析。5.3 日志层面定位热点 key在应用日志里按 key 维度统计未命中次数能帮你精确到“是哪个 key 出了问题”。很多框架或网关支持在访问日志里打印缓存 KEY简单做一下分组统计top N 的未命中 key 就出来了。如果 top N 里全是同一个业务前缀的乱序 ID比如 skuId 明显不是正常格式那基本可以实锤穿透攻击如果 top N 里只有一个 key比如某个大促商品的详情页那就是击穿现场。5.4 一张表帮你快速分流把上面的判断依据压成一张小表现象大概率方向下一步动作keyspace_misses 持续增长DB 查询返回空穿透查是否有异常 ID 扫描考虑空值缓存/布隆过滤器单 key missQPS 尖峰窄、很快恢复击穿分析热点 key加互斥锁或逻辑过期大量 key 同进同出地 miss或 Redis 不可用雪崩检查 TTL 策略、预热逻辑、Redis 高可用状态这张表我在不同团队里反复用过基本能覆盖线上告警的绝大部分场景。重点不是死记表而是掌握先看 Redis、再看 DB、最后落到具体 key 的排查顺序。6. 一套组合方案把穿透、击穿、雪崩一次管住6.1 一个综合读流程的伪代码真有准备把三大问题一次治理干净的团队我建议直接落地一个组合读流程而不是针对每个问题单独打补丁。public Object get(String key) { // 1. 本地缓存 Object local localCache.getIfPresent(key); if (local ! null) { return local; } // 2. 布隆过滤器拦截不存在的 key if (!bloomFilter.mightContain(key)) { return null; } // 3. Redis 缓存 String cache redis.get(key); if (cache ! null) { CacheEntry entry JSON.parse(cache); if (entry.expireAt now) { // 更新本地缓存注意控制一致性窗口 localCache.put(key, entry.data); return entry.data; } // 逻辑过期异步刷新 asyncRefresh(key); return entry.data; } // 4. 互斥锁兜底只让一个线程回源 String token UUID.randomUUID().toString(); if (redis.set(lock: key, token, NX, EX, 10)) { try { String cacheAgain redis.get(key); if (cacheAgain ! null) { return JSON.parse(cacheAgain).data; } Object dbValue db.get(key); if (dbValue null) { // 空值缓存也要做 redis.set(key, new CacheEntry(null, now 60), 60); return null; } int ttl 600 random.nextInt(300); redis.set(key, new CacheEntry(dbValue, now ttl), ttl); localCache.put(key, dbValue); return dbValue; } finally { if (token.equals(redis.get(lock: key))) { redis.del(lock: key); } } } sleep(50); return get(key); }这套流程把前面提到的所有手段都串进了同一条链路每一层负责拦截不同类型的异常流量。布隆过滤器拦穿透互斥锁和逻辑过期防击穿TTL 随机化防批量过期本地缓存兜底 Redis 不可用空值缓存拦住重复查询。单看任何一层都不是万能的但组合起来以后数据库被流量直接打穿的窗口会缩小一大截。6.2 不同业务场景下的选型组合这套流程不是所有系统都要完整上。我建议按业务阶段来中小系统、总请求量不大先做参数校验、空值缓存、TTL 随机化成本最低收益最直接。请求量上了百万、存在明显热点加入互斥锁或逻辑过期解决击穿。频繁被扫描、攻击特征明显加入布隆过滤器配合网关限流。核心链路、对可用性要求高加上多级缓存和降级比例控制防止 Redis 整体不可用时拖垮数据库。表格化选型参考场景推荐组合主要目标中小业务起步入口校验 空值缓存 TTL 随机化低成本挡住大部分穿透高并发热点明显上面 互斥锁/逻辑过期防止单 key 失效冲击 DB存在恶意扫描上面 布隆过滤器拦截不存在的 key核心链路高可用上面 多级缓存 降级缓存层不可用时保 DB6.3 这套体系里最容易翻车的几个细节组合方案跑起来以后有几个坑我真是每次都见到提前写出来布隆过滤器和新增数据脱节。如果业务上新增了一个 key但没同步更新布隆过滤器请求会被拦截白白丢掉正常用户。所以要么在数据写入链路上强制更新布隆过滤器要么定期全量重建。TTL 随机范围太小。如果基础 TTL 是 600 秒随机范围 0 到 10 秒那这个随机化等于没做大量 key 还是会在几分钟内挤在一起过期。随机范围建议至少覆盖基准时间的十分之一。逻辑过期没有单独的线程池。如果在请求线程里执行异步刷新高并发时线程池被打满刷新任务只会越积越多。给缓存刷新单独一个固定大小线程池并做好任务去重。锁的过期时间小于回源耗时。一旦锁先过期其他线程就能再次抢到锁数据库又会涌入多个回源请求。回源耗时估算要留足冗余。空值缓存和布隆过滤器同时用的时候顺序要注意。布隆过滤器判断不存在就直接返回那么空值缓存是用来兜底“布隆过滤器误判之后进入缓存链路”的少数请求两者不冲突。6.4 我现在的固定做法最后说点我自己在项目里的固定习惯。每次接到缓存相关告警我不急着改代码先看监控面板把问题定性命中率走势、DB 的 QPS 曲线、Redis 侧的主从状态、应用日志里的 TOP 未命中 key四样东西看一遍三大问题基本能分辨出来。然后再决定是加空值缓存、布隆过滤器还是互斥锁。治理手段本身不难难的是在流量真正打过来之前把它提前部署好。如果业务还没有遇到过穿透攻击或大促尖峰我建议可以先把这些方案在压测环境里跑一轮让 Redis 命中率、DB 压力这些指标形成基准数据。真到了线上手里有这些数据定位问题会快得多。
先从一段我亲身经历的线上事故说起。某个周二下午监控面板上数据库连接数从 200 一路跳到 2000Redis 命中率从 99% 肉眼可见地往下掉。第一反应是缓存挂了但 Redis 明明还活着数据库那边已经满屏慢查询连接池马上要被打满。排查到最后发现有人用一批不存在的商品 ID 在刷接口每次请求都是缓存没有、数据库也没有最后只能直接返回空。这个场景就是经典的 Redis 缓存穿透。说实话缓存穿透、缓存击穿、缓存雪崩这三件事很多同学面试前背得滚瓜烂熟但真到了线上遇到告警反而分不清自己遇到的是哪一种。这篇文章我不打算按教科书的方式念定义而是想还原一下这三个问题在真实业务里的表现、排查链路、以及我实际用过的解决方案。如果你是正在维护偏读多写少、请求量上百万的系统或者正准备从零把缓存治理做到位这篇应该能帮你省不少时间。1. 先看一条旁路缓存链路再谈三个“事故现场”1.1 旁路缓存的标准姿势使用 Redis 作为缓存最常见的架构是旁路缓存模式。请求进来先查 Redis命中直接返回没命中就去查询数据库拿到结果后把数据回填到 Redis再返回给调用方。这样的好处是 Redis 只承担“缓存”职责数据库是唯一的数据源逻辑简单也不容易出现缓存和数据库之间的强一致性问题。这里两个角色各管一边Redis 挡掉大部分重复请求数据库负责真正捞数据。这个架构本身没有问题问题出在“没命中”的时候。当请求量足够大一个“没命中”的请求落到数据库数据库还能扛但一万个、十万个“没命中”同时落下去数据库就很容易成为单点瓶颈。1.2 缓存未命中的不止一种走向同样是“缓存没命中”背后其实有三条完全不同的路径穿透key 本身就不存在数据库里也没有。缓存和数据库全部落空每次请求都在白忙活。击穿key 存在但这个热点 key 恰好到了过期时间。缓存没了数据库里有一瞬间所有并发请求都冲去数据库捞。雪崩大量 key 集中在同一时刻失效或者 Redis 节点直接不可用。整个缓存层失效数据库接住全部流量。这三条路径看起来都是“缓存没数据”但是成因不同、影响范围不同、修复手段也完全不同。如果分不清去线上改配置基本就是拆了东墙补西墙。我用一个表格快速画一下边界问题本质影响范围典型触发场景缓存穿透数据不存在缓存永远没数据单个请求/持续高频恶意刷不存在的 ID、漏填缓存空值缓存击穿单个热点 key 过期单 key 大并发秒杀商品、热帖、热点榜单缓存雪崩批量 key 过期或缓存层不可用全局性批量预热、TTL 统一、Redis 宕机1.3 为什么面试总爱问这三兄弟其实不只是面试题好看而是每一个上规模的系统都很难绕开这些问题。我在不同团队做过缓存治理凡是流量上到一定量级几乎都会在某个时段遇到其中一种。能不能在第一时间判断出是哪一个问题决定了你是能把故障摁在五分钟内还是要加班到凌晨两点。所以了解三大问题的本质比死记几条解决方案值钱得多。2. 缓存穿透数据库在替一个不存在的 key 加班2.1 穿透的典型特征穿透的核心特征是“查了个不存在的东西”。正常业务里用户查一个已经被删除的商品或者攻击者故意构造大量不存在的 ID缓存里没有任何记录数据库查询结果为空也没有人把空结果写回缓存。于是每一次请求都走完整的“Redis 未命中 - 数据库查询 - 返回空”链路。这个问题的可怕之处在于单个请求的代价很低但请求量一旦放大数据库就变成了单纯替不存在的 key 做无意义的查询。我曾经见过一个外包系统的接口因为没有对参数做任何约束被人用脚本按 ID 递增去扫描数据库直接被打到连接池耗尽业务全部接口跟着挂掉。2.2 方案一空值缓存别让数据库反复回答“没有”穿透最直接的解法就是把“查不到”这个结果也缓存起来。也就是当数据库查询结果为空时不是直接返回而是写入一个特定标记到 Redis设置一个相对短的 TTL例如 60 秒。后续同样的 key 再进来直接命中这个空值缓存不会再落到数据库。一个简单的伪代码示例Object value redis.get(key); if (value ! null) { return value; } // 这里才走数据库 Object dbValue db.get(key); if (dbValue null) { // 把空值也缓存起来TTL 要短 redis.set(key, EMPTY, 60); return null; } redis.set(key, dbValue, 300); return dbValue;这里有几个实操上的坑我踩过空值 TTL 不能太长。如果这个 key 很快被写入真实数据用户看到的还是空值缓存导致数据一致性延迟。建议控制在几十秒到几分钟之间。空值缓存也不能完全没有。如果这个空 key 是持续被高频访问的每次过期后还是会穿透到数据库。所以空值缓存 TTL 可以短但要比请求频率更合理。遇到 List、Hash 这类结构空值可以缓存为空集合避免客户端在 null 和空集合之间做额外判断。2.3 方案二布隆过滤器在缓存之前先挡一轮空值缓存解决的是“查过一次”的不存在 key但如果攻击者每次都换新 ID空值缓存形同虚设这时候要考虑布隆过滤器。布隆过滤器的原理不复杂一个位数组加上若干哈希函数。写入某个 key 时对 key 算 k 次哈希把位数组对应位置置为 1判断某个 key 是否存在时同样算 k 次哈希看这些位是否都是 1。只要有一个位是 0就能确定这个 key 一定不存在全为 1只能说“可能存在”。它对“不存在”的判断是绝对的对“存在”的判断存在一定误判率但不漏判。这就非常适合放在缓存查询之前先判断 key 是否可能存在如果连可能存在都谈不上直接返回数据库连一次查询都不用做。接入的时候大概是这样// 初始化阶段把全量存在的 key 灌进布隆过滤器 for (String id : allIds) { bloomFilter.put(id); } public Object get(String key) { // 布隆过滤器先判断 if (!bloomFilter.mightContain(key)) { return null; } // 之后才走缓存和数据库 Object value redis.get(key); if (value null) { Object dbValue db.get(key); // ... 正常回源逻辑 } return value; }落地的时候有个容易忽略的问题Redis 本身没有内置布隆过滤器你需要用 RedisBloom 模块提供 BF.ADD、BF.EXISTS 命令或者直接用位图SETBIT/GETBIT自己实现一套。我建议优先用 RedisBloom社区方案成熟也避免自己实现哈希函数时踩各种数学坑。至于内存估算可以用公式 m -n * ln(p) / (ln 2)^2其中 n 是预估 key 数量p 是期望的误判率。100 万条数据误判率 1%大概需要 1.2MB 的位数组这个成本完全可接受。这里有一个很重要的注意点布隆过滤器不适合频繁增删 key 的场景因为删除一个 key 时你不能简单把对应位还原为 0那会影响其他 key 的判断。所以如果业务上 key 集合变化非常快你需要考虑定期重建过滤器或者用带删除能力的 Cuckoo Filter不过那又是一个新话题了。2.4 方案三入口校验这些流量压根不该进来有些穿透流量其实在入口就能拦下来。比如商品 ID 有固定格式和范围用户 ID 有状态提前做参数校验把不合法、越界、明显是脚本构造的参数直接拒绝数据库连压力都感知不到。这类校验虽然看起来很简单但经常被忽略。我见过不少项目在网关层只做了鉴权没做参数合法性校验结果一个公开的列表接口被循环扫 ID硬生生扫出一个穿透事故。入口校验应该是成本最低的第一道防线但不是唯一的防线因为总会有一些合法但不存在的 ID 漏过去。2.5 穿透场景的实际注意事项总结一下穿透治理的经验教训空值缓存解决的是“同一个 key 反复查询”它能把重复穿透拦住布隆过滤器解决的是“不断换 key 的扫描”它能把不存在的 key 直接挡在缓存链路之外参数校验解决的是“明显不合法的请求”它负责降低进入系统的垃圾流量三个手段可以叠加但没必要一开始就全上先看监控曲线再决定在哪一层做加固。3. 缓存击穿热点 key 失效的那一秒流量全压向数据库3.1 击穿为什么比穿透更隐蔽如果说穿透是“查了个不存在的东西”击穿就是“查了个存在但恰好过期了的热点东西”。正常情况下热点 key 的请求几乎全部命中缓存数据库很轻松。但 key 到了过期时间缓存里那一瞬间没有数据大量并发请求同时发现未命中一起冲到数据库数据库在一秒内被灌进平时几个小时的请求量。击穿比穿透更隐蔽是因为它的窗口非常短。穿透可以通过持续请求观察到命中率持续走低击穿可能就发生在几秒钟之内等你打开监控面板的时候Redis 已经回填了新的缓存数据库也缓过来了现场已经没了只剩下数据库中残留的慢查询。典型场景秒杀商品详情页、热榜 Top 1 的帖子、直播间的某个爆款商品。这些 key 的并发量足够高一旦失效就可以造成 QPS 尖峰。3.2 互斥锁只让一个请求回源重建击穿第一反应是加锁。让缓存失效后只允许一个线程去数据库查询并重建缓存其他线程等待缓存重建完成或者直接快速返回旧值。Redis 在做这种分布式锁时很顺手用一条 SET 带上 NX 和 EX 即可String token UUID.randomUUID().toString(); Object value redis.get(key); if (value ! null) { return value; } // 尝试加锁只允许一个线程回源 if (redis.set(lock: key, token, NX, EX, 10)) { try { // 拿到锁后要二次检查缓存 value redis.get(key); if (value ! null) { return value; } Object dbValue db.get(key); redis.set(key, dbValue, 300); return dbValue; } finally { // 只删除自己加的锁 String lockValue redis.get(lock: key); if (token.equals(lockValue)) { redis.del(lock: key); } } } // 没抢到锁短暂等待后重试 sleep(50); return get(key);这里有三个细节必须注意拿到锁之后要二次检查缓存避免多线程在锁上排队结果第一个线程已经重建完缓存后面的线程又去数据库跑一遍。锁要设置过期时间防止自身宕机或 GC 停顿导致锁永久不释放形成死锁。释放锁时要校验是不是自己的锁否则可能误删别的线程刚创建的锁。以前很多人会把锁这块做重直接引入 Redisson 那套带看门狗的分布式锁。但如果你只想解决“热点 key 回源”这一个问题一条 SET NX 就够没必要为了一个缓存重建引入全套分布式锁体系。3.3 逻辑过期缓存永不过期数据异步刷新互斥锁最大的缺点是如果回源重建非常慢其他线程都在自旋等待虽然不会压爆数据库但接口 RT 会很难看。更优的实践是“逻辑过期”。思路很简单key 不设置物理 TTLvalue 里存一份数据本身和逻辑过期时间。读取的时候比较当前时间与逻辑过期时间如果还没过期正常返回如果已经过期先把旧数据返回给调用方同时提交一个异步任务去数据库查询并更新缓存。// 缓存结构data 逻辑过期时间 redis.set(key, JSON.stringify(new CacheEntry(dbValue, now 600))); public Object get(String key) { String cache redis.get(key); if (cache null) { // 这里还是要配合互斥锁或布隆过滤器处理 return db.get(key); } CacheEntry entry JSON.parse(cache); if (entry.expireAt now) { return entry.data; } // 逻辑过期先返回旧数据异步重建 asyncRefresh(key); return entry.data; }逻辑过期方案的关键收获是缓存永远在读请求永远不会打到数据库上去。代价是数据会有短暂的不一致大促场景下这种短暂陈旧往往是可接受的但对一致性要求高的业务就不太适合。异步刷新这里也要注意如果并发很高可能出现大量异步任务同时回源。最简单的方式是在异步刷新前也尝试加一次互斥锁只让一个任务真正执行数据库查询其他任务直接丢弃。3.4 击穿方案的选型建议我的取舍标准是这样的如果回源很快简单 SQL 加一次查询耗时在几十毫秒内互斥锁就够了实现简单数据一致性好如果回源很慢涉及远程调用、复杂计算耗时几百毫秒甚至秒级优先逻辑过期不要让请求在线等待如果业务对一致性要求极高同时回源又快那还是互斥锁更稳。大部分互联网场景秒杀、热榜这种热点 key回源往往很快我实际用得最多的是互斥锁。逻辑过期更多地是用在“查一次很贵”的复杂聚合场景。4. 缓存雪崩批量过期和 Redis 宕机带来的连锁反应4.1 第一类雪崩大量 key 同时过期的现场雪崩最典型的一个形态是“缓存里一大片 key 在同一时刻集体失效”。这个现象的制造过程通常是这样的系统上线的时候做了一次缓存预热把一批数据循环写入所有 key 用了同一个 TTL。等到这批 key 同时过期原本被缓存挡掉的流量在下一个时刻全部涌向数据库。数据库可能在几分钟内就被打挂随后大量超时请求堆积进程反复重试最终形成连锁反应。这跟击穿的区别在于范围。击穿是一个 key 的并发问题雪崩是一批 key 的并发问题。一个 key 一秒内几百个请求打向数据库数据库也许能扛一百个 key 同时这么来大概率没人扛得住。4.2 应对策略让过期时间“错峰”第一类雪崩的解决思路其实很朴素别让所有 key 在同一时刻过期。业界标准做法是在基础 TTL 上加上一个随机值。int baseTtl 600; int ttl baseTtl random.nextInt(300); redis.set(key, value, ttl);这个随机值看着简单但非常有效。它把“集体过期”变成“分批过期”每个 key 过期的时刻错开数据库在同一时间收到的回源请求就被摊薄了。另外一个容易忽略的点是缓存预热。启动时批量写入缓存如果不做任何错峰所有 key 几乎同时写进去也就意味着它们也会几乎同时过期。所以预热的时候同样要按批次分散时间或者每批使用不同的 TTL 基准。4.3 第二类雪崩Redis 节点不可用比大量 key 过期更严重的是整个 Redis 实例不可用。比如单个 Redis 节点宕机主从切换瞬间缓存层的读取全部失败流量直接落到数据库如果此时数据库扛不住就会引发第二轮故障业务重试、消费者堆积、连接池耗尽。这里我要专门说一下很多人听到 Redis 高可用就想到主从、哨兵、集群这方向没错但有个容易被忽略的细节高可用只能减少宕机时间不能消除宕机瞬间的缓存穿透窗口。主从切换的几秒钟里缓存查询是会失败的你必须搞清楚应用层在这几秒钟怎么处理。如果应用把缓存查询失败当成“请求失败直接报错”那问题不大只是这一小部分请求失败了但如果应用把缓存查询失败当成“缓存未命中”去查数据库那数据库就会在几秒钟内收到大量回源请求同样有风险。所以异常处理和降级策略要提前定义。4.4 高可用架构与持久化兜底在架构层面主从加哨兵是单实例高可用的基础玩法哨兵负责监控和自动切换Redis Cluster 则更适合数据量大、并发高的场景分片加副本可以同时解决容量和可用性问题。持久化在这里的作用容易被低估。Redis 宕机重启后如果没有持久化内存里全空缓存层等于冷启动大量请求直接打向数据库这时候等于人为制造了一次雪崩。开启 RDB 做定期快照、AOF 做操作日志重启后可以尽快恢复大部分缓存数据把冷启动的冲击降到最低。这也是很多团队把“持久化机制到底要不要开”这个题聊得很深的原因。持久化和性能是有取舍的。高写入场景下 AOF 的同步策略要权衡但为了缓存层重启不冷场我通常建议至少开启 RDB 快照再根据数据重要性决定 AOF 的同步级别。4.5 多级缓存和降级让系统在极端情况还能喘气不管是批量过期还是 Redis 宕机真正兜底的方案是多级缓存加降级策略。多级缓存常见的做法是JVM 内本地缓存比如 Caffeine做第一级Redis 做第二级数据库做最后一级。热点 key 可以在本地缓存里放一份设置一个比较短的 TTL比如 30 秒。Redis 不可用的时候本地缓存还能挡住相当一部分读请求。降级策略则要定义清楚缓存不可用时是直接让请求走数据库还是返回一个降级页面/默认数据。我的建议是给核心链路设置一个“允许穿透到数据库的比例”比如正常情况下 5% 的流量可以落到数据库剩下的直接走降级当数据库压力也接近门槛时这个比例再往下调甚至完全阻断回源。多级缓存也不是万能的本地缓存有数据一致性问题。每次写入 Redis 时可以考虑同步更新本地缓存或者接受最长几十秒的不一致这个需要业务侧评估。但是用多级缓存对抗雪崩方向肯定是对的。5. 遇到线上告警如何反向判断是穿透、击穿还是雪崩5.1 Redis 侧能看到的证据接到告警以后的第一个动作我永远是打开缓存命中率。用 Redis 的 INFO stats 命令看两个数字keyspace_hits 和 keyspace_misses。miss 数在短时间内突然增加第一步就跑不掉穿透冲击。平时我习惯在 Another Redis Desktop Manager 这种可视化客户端里看这几个指标的曲线感觉比命令行直观命中率从 99% 掉到 80%伴随数据库慢查询上升基本可以断定有不正常流量在穿透缓存层。再配合 Redis 的 slowlog 和 monitor能进一步看清是哪些 key 在被频繁访问。不过 monitor 在高流量下会拖累 Redis 性能线上最好只在短时间内使用或干脆不用更多依赖业务日志。5.2 数据库侧的慢查询和 QPS 曲线数据库侧的证据更直观。如果数据库 QPS 曲线出现一个非常窄的尖峰过了就恢复正常大概率是击穿某个热点 key 过期了重建完成之后流量又回到缓存。如果 QPS 曲线持续走高迟迟不回落更像穿透不断有不存在的 key 在打数据库。如果数据库 QPS 瞬间打满、随后 Redis 侧也出现主从切换日志或节点重启记录那基本就是雪崩。这时候去查缓存层高可用状态而不是盯着单个 key 分析。5.3 日志层面定位热点 key在应用日志里按 key 维度统计未命中次数能帮你精确到“是哪个 key 出了问题”。很多框架或网关支持在访问日志里打印缓存 KEY简单做一下分组统计top N 的未命中 key 就出来了。如果 top N 里全是同一个业务前缀的乱序 ID比如 skuId 明显不是正常格式那基本可以实锤穿透攻击如果 top N 里只有一个 key比如某个大促商品的详情页那就是击穿现场。5.4 一张表帮你快速分流把上面的判断依据压成一张小表现象大概率方向下一步动作keyspace_misses 持续增长DB 查询返回空穿透查是否有异常 ID 扫描考虑空值缓存/布隆过滤器单 key missQPS 尖峰窄、很快恢复击穿分析热点 key加互斥锁或逻辑过期大量 key 同进同出地 miss或 Redis 不可用雪崩检查 TTL 策略、预热逻辑、Redis 高可用状态这张表我在不同团队里反复用过基本能覆盖线上告警的绝大部分场景。重点不是死记表而是掌握先看 Redis、再看 DB、最后落到具体 key 的排查顺序。6. 一套组合方案把穿透、击穿、雪崩一次管住6.1 一个综合读流程的伪代码真有准备把三大问题一次治理干净的团队我建议直接落地一个组合读流程而不是针对每个问题单独打补丁。public Object get(String key) { // 1. 本地缓存 Object local localCache.getIfPresent(key); if (local ! null) { return local; } // 2. 布隆过滤器拦截不存在的 key if (!bloomFilter.mightContain(key)) { return null; } // 3. Redis 缓存 String cache redis.get(key); if (cache ! null) { CacheEntry entry JSON.parse(cache); if (entry.expireAt now) { // 更新本地缓存注意控制一致性窗口 localCache.put(key, entry.data); return entry.data; } // 逻辑过期异步刷新 asyncRefresh(key); return entry.data; } // 4. 互斥锁兜底只让一个线程回源 String token UUID.randomUUID().toString(); if (redis.set(lock: key, token, NX, EX, 10)) { try { String cacheAgain redis.get(key); if (cacheAgain ! null) { return JSON.parse(cacheAgain).data; } Object dbValue db.get(key); if (dbValue null) { // 空值缓存也要做 redis.set(key, new CacheEntry(null, now 60), 60); return null; } int ttl 600 random.nextInt(300); redis.set(key, new CacheEntry(dbValue, now ttl), ttl); localCache.put(key, dbValue); return dbValue; } finally { if (token.equals(redis.get(lock: key))) { redis.del(lock: key); } } } sleep(50); return get(key); }这套流程把前面提到的所有手段都串进了同一条链路每一层负责拦截不同类型的异常流量。布隆过滤器拦穿透互斥锁和逻辑过期防击穿TTL 随机化防批量过期本地缓存兜底 Redis 不可用空值缓存拦住重复查询。单看任何一层都不是万能的但组合起来以后数据库被流量直接打穿的窗口会缩小一大截。6.2 不同业务场景下的选型组合这套流程不是所有系统都要完整上。我建议按业务阶段来中小系统、总请求量不大先做参数校验、空值缓存、TTL 随机化成本最低收益最直接。请求量上了百万、存在明显热点加入互斥锁或逻辑过期解决击穿。频繁被扫描、攻击特征明显加入布隆过滤器配合网关限流。核心链路、对可用性要求高加上多级缓存和降级比例控制防止 Redis 整体不可用时拖垮数据库。表格化选型参考场景推荐组合主要目标中小业务起步入口校验 空值缓存 TTL 随机化低成本挡住大部分穿透高并发热点明显上面 互斥锁/逻辑过期防止单 key 失效冲击 DB存在恶意扫描上面 布隆过滤器拦截不存在的 key核心链路高可用上面 多级缓存 降级缓存层不可用时保 DB6.3 这套体系里最容易翻车的几个细节组合方案跑起来以后有几个坑我真是每次都见到提前写出来布隆过滤器和新增数据脱节。如果业务上新增了一个 key但没同步更新布隆过滤器请求会被拦截白白丢掉正常用户。所以要么在数据写入链路上强制更新布隆过滤器要么定期全量重建。TTL 随机范围太小。如果基础 TTL 是 600 秒随机范围 0 到 10 秒那这个随机化等于没做大量 key 还是会在几分钟内挤在一起过期。随机范围建议至少覆盖基准时间的十分之一。逻辑过期没有单独的线程池。如果在请求线程里执行异步刷新高并发时线程池被打满刷新任务只会越积越多。给缓存刷新单独一个固定大小线程池并做好任务去重。锁的过期时间小于回源耗时。一旦锁先过期其他线程就能再次抢到锁数据库又会涌入多个回源请求。回源耗时估算要留足冗余。空值缓存和布隆过滤器同时用的时候顺序要注意。布隆过滤器判断不存在就直接返回那么空值缓存是用来兜底“布隆过滤器误判之后进入缓存链路”的少数请求两者不冲突。6.4 我现在的固定做法最后说点我自己在项目里的固定习惯。每次接到缓存相关告警我不急着改代码先看监控面板把问题定性命中率走势、DB 的 QPS 曲线、Redis 侧的主从状态、应用日志里的 TOP 未命中 key四样东西看一遍三大问题基本能分辨出来。然后再决定是加空值缓存、布隆过滤器还是互斥锁。治理手段本身不难难的是在流量真正打过来之前把它提前部署好。如果业务还没有遇到过穿透攻击或大促尖峰我建议可以先把这些方案在压测环境里跑一轮让 Redis 命中率、DB 压力这些指标形成基准数据。真到了线上手里有这些数据定位问题会快得多。
