14人参与 • 2025-07-22 • Redis
大量缓存数据在同一时间失效,导致所有请求直接打到数据库,引发数据库瞬时高负载甚至崩溃
1、缓存数据设置了相同的过期时间
2、缓存服务宕机
在基础ttl上增加随机值,避免同时失效
结合本地缓存和分布式缓存,本地缓存失效后回源到分布式缓存
监控数据库负载,超过阈值时触发熔断(如返回默认值或限流)
缓存不设ttl,通过后台任务定期更新(适合低频变更数据)
某个热点key突然失效,大量并发请求直接穿透到数据库,导致数据库压力激增
1、热点key过期
2、恶意请求故意攻击高频访问的key
第一个请求发现缓存失效时,加锁(如redis setnx),从数据库加载数据后释放锁,其它请求等待或轮询
1、缓存永不过期,但存储数据时附加一个过期时间字段
2、发现数据逻辑过期时,触发异步更新
监控热点key,在接近过期时提前刷新缓存
查询不存在的数据(如非法id、恶意攻击),导致请求绕过缓存直接访问数据库
1、业务逻辑漏洞(如未校验参数合法性)
2、恶意攻击(如爬虫伪造不存在的id)
对查询不到的数据,混存一个空值,并设置较短ttl
在缓存层前加布隆过滤器,快速判断key是否存在:若布隆过滤器返回不存在,直接拒绝请求;若返回可能存在,继续查询缓存/数据库
对请求参数做合法性校验
问题 | 触发条件 | 核心解决方案 |
---|---|---|
缓存雪崩 | 大量key同时失效 | 差异化ttl、多级缓存、熔断降级 |
缓存击穿 | 单个热点key失效 | 互斥锁、逻辑过期、预加载 |
缓存穿透 | 查询不存在的数据 | 布隆过滤器、控制缓存、参数校验 |
1、监控与告警:实时监控缓存命中率、数据库qps,设置阈值告警
2、压测模拟:通过模拟雪崩/击穿场景,验证解决方案的可靠性
3、组合策略:根据业务场景混合使用上述方案
以上为个人经验,希望能给大家一个参考,也希望大家多多支持代码网。
您想发表意见!!点此发布评论
版权声明:本文内容由互联网用户贡献,该文观点仅代表作者本人。本站仅提供信息存储服务,不拥有所有权,不承担相关法律责任。 如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 2386932994@qq.com 举报,一经查实将立刻删除。
发表评论