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

本文介绍了缓存击穿、缓存穿透和缓存雪崩三种常见缓存问题及其解决方案。缓存击穿是key过期后大量请求到达数据库;解决方案包括设置互斥锁、提前使用互斥锁和永远不过期。缓存穿透是请求数据库中不存在的key,可能引发数据库压力;解决方案包括使用过滤器和为为空key设置短暂缓存。缓存雪崩则是大量缓存同一时间失效,解决方案是加锁或错开失效时间。

缓存击穿

  定义: 缓存中的key一般设有过期时间,如果某个key过期了,恰在这个时候,有大量的并发请求访问这个key,则这些请求都会到达DB,导致DB瞬间压力过大,压垮DB。

  解决方案: 1.设置互斥锁,mutex。当缓存失效时不时立即去访问数据库,而是使用缓存工具的操作成功带返回值的操作,比如redis的setnx(set if not exit),memcache的add,利用setnx实现锁的效果。

缺点:可能造成死锁,或线程池阻塞

2.提前使用互斥锁
redist的超时时间是timeout1,value的超时时间是timeout2,timeout2 < timeout1。 当timeout2超时时,延长timeout2的时间。并重新设置到redis中。

3.永远不过期
不设置过期时间。
把过期时间设到value里,如果快要过期了,通过一个后台异步线程进行缓存的构建,也就是逻辑过期。

缓存穿透

  定义: 指有人用数据库中不存在的某个key访问,数据库中没有该key值,自然缓存中也不会有,该请求会直接到数据库。如果对该key的并发访问量过大,则会压垮数据库。

  解决方案:
1. 采用过滤器,把所有数据库中不可能存在的数据hash到一张大的bitmap中,如果key在数据库中不存在,将会被bitmap拦截。
2. 对查出为空的key,也在缓存中简历key value对,只是过期时间设的短一点,比如5minetes。

缓存雪崩

  定义: 指缓存中大量的数据在同一时间失效,这时有大量的请求会被直接转到数据库,造成数据库的压力过大。

<

<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]。
评论 13
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值