缓存穿透与缓存雪崩

缓存穿透

什么是缓存穿透?

一般的缓存系统,都是按照key去缓存查询,如果不存在对应的value,就应该去后端系统查找(比如DB)。如果key对应的value是一定不存在的,并且对该key并发请求量很大,就会对后端系统造成很大的压力。这就叫做缓存穿透。
 

如何避免?

1:对查询结果为空的情况也进行缓存,缓存时间设置短一点,或者该key对应的数据insert了之后清理缓存。
2:对一定不存在的key进行过滤。可以把所有的可能存在的key放到一个大的Bitmap中,查询时通过该bitmap过滤。【感觉应该用的不多吧】

缓存雪崩

什么是缓存雪崩?

当缓存服务器重启或者大量缓存集中在某一个时间段失效,这样在失效的时候,也会给后端系统(比如DB)带来很大压力。

如何避免?

1:在缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存,其他线程等待。
2:不同的key,设置不同的过期时间,让缓存失效的时间点尽量均匀。
3:做二级缓存,A1为原始缓存,A2为拷贝缓存,A1失效时,可以访问A2,A1缓存失效时间设置为短期,A2设置为长期(此点为补充)
 

分布式缓存系统

分布式缓存系统面临的问题

缓存一致性问题

1:缓存系统与底层数据的一致性。这点在底层系统是“可读可写”时,写得尤为重要

2:有继承关系的缓存之间的一致性。为了尽量提高缓存命中率,缓存也是分层:全局缓存,二级缓存。他们是存在继承关系的。全局缓存可以有二级缓存来组成。

3:多个缓存副本之间的一致性。为了保证系统的高可用性,缓存系统背后往往会接两套存储系统(如memcache,redis等)

缓存穿透和缓存雪崩
上面有讲述。
 

缓存数据的淘汰

缓存淘汰的策略有两种: (1) 定时去清理过期的缓存。 (2)当有用户请求过来时,再判断这个请求所用到的缓存是否过期,过期的话就去底层系统得到新数据并更新缓存。
两者各有优劣,第一种的缺点是维护大量缓存的key是比较麻烦的,第二种的缺点就是每次用户请求过来都要判断缓存失效,逻辑相对比较复杂,具体用哪种方案,大家可以根据自己的应用场景来权衡。
 
1. 预估失效时间 2. 版本号(必须单调递增,时间戳是最好的选择)3. 提供手动清理缓存的接口。
<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、付费专栏及课程。

余额充值