缓存穿透、缓存击穿与缓存雪崩

本文详细解释了缓存穿透、缓存击穿和缓存雪崩的区别,提供了针对这些问题的解决方案,包括使用布隆过滤器避免穿透攻击,互斥锁处理击穿问题,以及通过随机化过期时间来缓解雪崩现象。

缓存穿透、缓存击穿与缓存雪崩

1.本质区别

缓存穿透指的是数据库不存在数据,导致无法缓存,每次查询都查数据库,数据库压垮

缓存击穿指的是缓存键值对key过期了,key过期期间,大量请求访问,不经过缓存,直接请求数据库,数据库压垮

缓存雪崩指的是key同时过期,请求不经缓存全部到数据库,数据库压垮

2.根据各自特点解决方案

缓存穿透

1.查询为null,将null缓存,key过期时间设置短一些,主要防止恶性攻击

2.redisson实现的布隆过滤器,底层bitmap,里面存的是二进制0和1,。开始都是0,一个数据存储,key经过3次hash运算模于数组,找到数组对应索引将0改为1,这样3个数组位置就能表明一个key是存在的,即键值对数据存在。但存在误判(C不存在,hash运算取模,1个值属于A,2个值数据B,A与B均存在,三个数组位置都是1,会误判C存在),概率不超过5%

缓存击穿

1.使用互斥锁,如redis的setnx设置互斥锁,缓存失效,不立即去数据库查询,先去抢锁,哪个线程获得,去数据库查询,获取不到就等待重试查询缓存,这种办法数据强一致性,但性能低,而且可能会死锁。

2.key设置逻辑过期非实际物理过期,设置key的时候,设计一个过期时间字段一起存入缓存中,而不给key设置过期时间。查询的时候,从redis中取出判断时间是否过期,如果过期开通另一线程进行数据同步,当前线程正常返回数据(返回的是旧数据),这种办法性能高,但是无法做到数据强一致性

缓存雪崩

解决方案将原有失效时间上随机加上随机值,比如1-5分钟随机,这样就不会同一时刻大量的key同时失效,缓存过期时间重复率降低

<think>嗯,用户想深入理解缓存击穿穿透雪崩的区别及解决方案。从对话历史看,我之前已经给过详细对比表格和解决方案,但用户可能希望更直观的总结。 用户提供的引用内容很全面,特别是引用[4]的对比表格非常清晰。需要突出三个问题的核心差异点: 1. 穿透是查不存在的数据(恶意请求) 2. 击穿是热点key失效(突发流量) 3. 雪崩是大面积key同时失效(系统风险) 注意到用户特别标注要"区别+解决方案"并列呈现,所以考虑设计双栏结构:左栏特征描述,右栏对应解决方案。这样对比更鲜明。 关于解决方案的优先级: - 穿透首选布隆过滤器(引用[1][4]都强调) - 击穿重点在锁机制和逻辑过期(引用[3]示例代码很实用) - 雪崩需要TTL随机化+多级缓存(引用[2][5]都提到) 用户可能对实际场景更关注,准备补充电商案例: 1. 穿透:黑客用负数ID刷接口 2. 击穿:iPhone新品开售时缓存失效 3. 雪崩:整点秒杀活动缓存集中过期 最后要强调引用[5]的实践建议:监控命中率比事后补救更重要。考虑在总结部分加入这个观点。</think>以下是缓存击穿缓存穿透缓存雪崩的核心区别及解决方案的对比总结: --- ### **一、核心区别对比** | **问题类型** | **触发条件** | **本质原因** | **典型场景** | **影响范围** | |----------------|---------------------------------------|-------------------------------|-------------------------------|-----------------------| | **缓存穿透** | 查询**不存在的数据**(数据库也无记录) | 恶意攻击或业务异常[^4] | 频繁请求非法ID(如`user_id=-1`) | 持续冲击数据库 | | **缓存击穿** | **热点Key过期瞬间**遭遇高并发请求 | 单点失效引发雪崩效应[^3] | 热搜商品/秒杀活动Key过期 | 数据库瞬时压力剧增 | | **缓存雪崩** | **大量Key同时过期** | 缓存集中失效[^2] | 促销活动结束大批商品缓存失效 | 数据库被压垮甚至宕机 | > **关键公式**: > - 缓存雪崩风险:$$ Risk = \frac{N_{expired}}{N_{total}} \times QPS $$ > ($N_{expired}$:同时过期Key数量,$QPS$:请求量) --- ### **二、针对性解决方案** #### **1. 缓存穿透解决方案** - **布隆过滤器 (Bloom Filter)** - 前置位数组存储所有合法Key的哈希值,拦截非法请求[^4] - 内存优化:1亿Key仅需约120MB - 误判率公式:$$ P \approx \left(1 - e^{-\frac{k \cdot n}{m}}\right)^k $$ ($k$:哈希函数数量,$n$:元素数量,$m$:位数组大小) - **缓存空值 (Null Caching)** ```java // 伪代码示例 Object data = cache.get(key); if (data == null) { data = db.query(key); if (data == null) { cache.set(key, "NULL", 300); // 缓存空值300秒 } } ``` - 对空结果设置短时缓存(需定期清理)[^3] #### **2. 缓存击穿解决方案** - **互斥锁 (Mutex Lock)** ```python # Redis分布式锁伪代码 if not cache.exists(key): if redis.setnx("lock:"+key, 1, ex=10): # 获取锁 data = db.query(key) cache.set(key, data, ttl=60+randint(0,30)) # 回填缓存并随机TTL redis.delete("lock:"+key) else: time.sleep(0.05) # 等待50ms后重试 return cache.get(key) ``` - 仅允许一个线程重建缓存[^1] - **逻辑过期时间** - 缓存Value结构:`{"data": "真实数据", "expire": 1717020800}` - 异步更新:线程发现过期时触发更新,直接返回旧数据 #### **3. 缓存雪崩解决方案** - **TTL随机化** $$ TTL_{new} = TTL_{base} + random(0, 300) $$ 避免批量Key同时过期[^2] - **多级缓存架构** ```mermaid graph LR A[客户端] --> B[本地缓存 Caffeine] B --> C{命中?} C -->|是| D[返回数据] C -->|否| E[Redis集群] E --> F{命中?} F -->|是| D F -->|否| G[数据库] G --> H[回填各级缓存] ``` - 本地缓存Redis数据库 三级拦截[^5] - **熔断降级** 监控数据库QPS,超过阈值时启动限流(如Sentinel) --- ### **三、通用防御策略** | **策略** | 穿透 | 击穿 | 雪崩 | 实现复杂度 | |------------------|------|------|------|------------| | 布隆过滤器 | ✅✅✅ | ❌ | ❌ | 中 | | 互斥锁 | ❌ | ✅✅✅ | △ | 高 | | 缓存空值 | ✅✅ | ❌ | ❌ | 低 | | TTL随机化 | ❌ | △ | ✅✅✅ | 低 | | 多级缓存 | ✅ | ✅✅ | ✅✅ | 高 | | 热点Key永不过期 | ❌ | ✅✅ | ❌ | 中 | > **设计原则**: > - 穿透:**过滤非法请求**(布隆过滤器为核心) > - 击穿:**保障热点数据高可用**(锁+逻辑过期) > - 雪崩:**分散失效风险**(TTL随机化+多级缓存)[^4][^5] --- ### **四、典型场景案例** 1. **缓存穿透** - **场景**:黑客用脚本遍历用户ID(包括负数) - **方案**:布隆过滤器拦截非法ID请求[^1] 2. **缓存击穿** - **场景**:双11零点热门商品缓存失效 - **方案**:Redis分布式锁控制单线程回填缓存[^3] 3. **缓存雪崩** - **场景**:整点秒杀活动缓存集中过期 - **方案**:基础TTL=1小时 + 随机300秒偏移量[^2] --- ### **总结** | **问题** | **核心矛盾** | **必选方案** | |----------------|-----------------------|----------------------------| | 缓存穿透 | 非法请求穿透防线 | 布隆过滤器 + 空值缓存 | | 缓存击穿 | 单点失效引发雪崩 | 互斥锁 + 逻辑过期 | | 缓存雪崩 | 批量失效压垮数据库 | TTL随机化 + 多级缓存架构 | > 实践中需结合**监控告警**(缓存命中率、DB QPS)和**熔断降级**机制[^5]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值