缓存穿透雪崩

wen IT资讯 2026-07-02 24

从原理到实战的全面防御指南

目录导读

缓存穿透：当查询直接击穿数据库
缓存雪崩：批量失效引发的连锁崩塌
缓存穿透的终极解决方案
缓存雪崩的防护策略体系
常见问答FAQ

缓存穿透：当查询直接击穿数据库

1 定义与现象描述

缓存穿透是指查询一个根本不存在的数据，缓存层和持久层（如数据库）都无法命中，由于缓存没有该数据，请求会直接打到数据库，导致数据库压力暴增，如果攻击者恶意构造大量不存在的key并发访问，数据库可能直接崩溃。

缓存穿透雪崩

2 典型案例

某电商平台的热搜商品ID为10001~20000，攻击者构造ID=99999的无效商品查询，由于缓存中无此key，每次请求均穿透至数据库，数据库CPU瞬间飙升100%，正常用户请求被阻塞。

3 关键区别

缓存穿透：查询无效key，缓存和数据库均无数据。
缓存击穿：查询热点key失效瞬间，大量并发压向数据库。
缓存雪崩：大量key同时失效或缓存宕机，导致流量波峰冲击数据库。

核心公式：缓存穿透 = 不存在的数据 + 无限次查询

缓存雪崩：批量失效引发的连锁崩塌

1 定义与发生机制

缓存雪崩指大量缓存key在同一时间失效，或缓存服务节点宕机，导致所有请求直接落入数据库，不同于穿透针对单个不存在的key，雪崩是“大面积失效”的宏观灾难。

2 典型场景

定时批量失效：所有商品缓存统一设置过期时间为凌晨2点，2点01分涌入的100万并发全部命中数据库。
缓存节点宕机：Redis集群主节点故障，未开启Sentinel/Cluster模式，导致整个缓存层不可用。

3 雪崩的层级放大效应

用户请求 → 缓存未命中(批量失效) → 数据库瞬间承受10倍流量 → 连接池打满 → 应用层超时堆积 → 上游服务连锁崩溃

缓存穿透的终极解决方案

1 方案一：布隆过滤器（Bloom Filter）

原理：使用位数组+哈希函数，判断key是否可能存在，若不存在则直接拒绝，避免无效查询。
实战配置：初始化1亿bit位，3个哈希函数，误判率控制在1%以内。

代码示例（伪代码）：

bloom_filter = BloomFilter(max_elements=100000, error_rate=0.01)
if not bloom_filter.contains(key):
    return "数据不存在"
data = cache.get(key)
if not data:
    data = db.query(key)
    cache.set(key, data, ttl=60)

2 方案二：缓存空对象

操作：即使数据库查不到，也缓存一个空值（如“NULL”），设置极短过期时间（30~60秒）。
风险控制：配合布隆过滤器防止恶意空值堆积。

3 方案三：接口层参数校验

对可能穿透的ID进行正则校验、范围校验（如ID必须是1~100000的正整数）。

效率对比： | 方案 | 防穿透效果 | 内存占用 | 实现复杂度 | |------|------------|----------|------------| | 布隆过滤器 | 高（99%拦截） | 低 | 中 | | 缓存空对象 | 中（需短TTL） | 高（空key堆叠）| 低 | | 参数校验 | 低（仅过滤明显无效值） | 无 | 极低 |

缓存雪崩的防护策略体系

1 核心策略：过期时间随机化

问题根源：大量key相同TTL。
解决方案：在基础TTL上增加随机偏移量，TTL = base_ttl + random(60, 300) 秒。
实战效果：原本600秒统一失效，分散为600~900秒内随机失效，平抑波峰。

2 次级策略：缓存预热与双key机制

缓存预热：系统上线前，主动加载热点数据到缓存，避免瞬时空缓存。
双key主备：A key存活期1小时（TTL=3600），B key存活期2小时（TTL=7200），当A失效时，先尝试读B，异步重建A。

3 高级策略：限流与降级

本地限流：使用Sentinel或Guava RateLimiter限制单机QPS，超出部分直接返回友好提示。
熔断降级：若数据库QPS超过阈值（如5000/s），自动熔断缓存重建流程，返回静态数据或默认值。

4 架构级防护：Redis高可用 + 多级缓存

Redis集群：主从+Sentinel实现自动故障转移，避免单点宕机。
本地缓存+分布式缓存：nginx lua缓存+Redis+数据库三级架构，即使Redis不可用，仍有60%请求命中本地缓存。

雪崩防御公式：

雪崩抵抗力 = 随机化TTL × 限流熔断 × 缓存高可用 × 多级冗余

常见问答FAQ

Q1：布隆过滤器会不会让正常请求也被误拦截？

A：会存在极低误判率（1%内），但不会漏判，建议业务允许1%误判时使用，或配合缓存空对象二次确认，对于安全业务（如支付防重），不要依赖布隆过滤器做唯一判断。

Q2：缓存雪崩和缓存击穿，哪个危害更大？

A：雪崩影响范围更广（大量key vs 单个热点key），修复难度更大，击穿可通过“互斥锁+热点永不过期”解决；雪崩需要全量TTL治理和限流机制。

Q3：如果不小心删除了布隆过滤器的位数组，怎么解决？

A：可以使用可扩展布隆过滤器（Scalable Bloom Filter），支持动态扩容重建，生产环境建议布隆过滤器和缓存空对象方案双保险，避免强依赖。

Q4：对于微服务架构，如何统一管理缓存TLL？

A：使用配置中心（如Nacos/Apollo）动态下发TTL策略，系统监听配置变更后重新加载缓存，同时监控缓存命中率和数据库QPS，自动调整TTL随机范围。

Q5：多级缓存中，本地缓存和Redis的TTL如何配合？

A：采用瀑布式TTL：本地缓存TTL = 60秒，Redis TTL = 180秒，本地缓存失效后先回源Redis，Redis失效后再回源数据库，这样可以过滤掉90%的Redis冲击。

构建铁三角防御体系

防穿透：布隆过滤器 + 参数校验 + 空值缓存（短TTL）
防雪崩：随机TTL + 限流熔断 + Redis哨兵集群 + 本地缓存兜底
监控告警：实时监控缓存命中率、数据库QPS、失效key分布，一旦命中率低于80%自动触发扩容或降级

缓存穿透与雪崩并非偶然,而是系统容量规划不足的必然体现，通过本文的7种策略组合落地，可以做到即使恶意流量来袭，数据库依然稳定运行，同时保证99%以上请求在毫秒级响应。

最后提醒：线上验证时，建议先在压测环境模拟“10万并发穿透”“5万key同时失效”两种极端场景，验证防御体系的实际承压能力。