Redis-缓存雪崩、穿透、击穿

作者介绍：简历上没有一个精通的运维工程师。请点击上方的蓝色《运维小路》关注我，下面的思维导图也是预计更新的内容和当前进度(不定时更新)。

数据库是一个系统（应用）最重要的资产之一，所以我们的数据库将从以下几个数据库来进行介绍。

MySQL

PostgreSQL

MongoDB

Redis（本章节）

Etcd

上个小节我们介绍Redis的数据过期（TTL）,如果Redis作为业务数据的前端缓存，如果大量的key同时过期会出现什么情况呢？

Redis 缓存的雪崩、穿透、击穿是缓存架构中最常见的三类故障问题，三者的核心差异在于故障原因、影响范围和应对策略，下面结合原理、场景和解决方案进行详细拆解。

一、缓存雪崩

1. 定义：

大量缓存键在同一时间集体过期，或者 Redis 实例宕机，导致所有请求直接穿透到后端数据库，数据库瞬间承受海量请求而崩溃。

2. 核心原因：

过期时间集中：批量设置缓存时，给所有键配置了相同的过期时间，到时间后集体失效。示例：电商大促时，给所有商品缓存设置了 24 小时过期，24 小时后所有商品缓存同时失效。

• 缓存服务宕机：Redis 集群故障（如主从切换失败、节点宕机），导致缓存层完全不可用。

3. 典型影响：

• 数据库 CPU/IO 飙升，连接数打满，最终宕机；
• 业务系统出现超时、报错，用户请求失败。

4. 解决方案

1. 给过期时间添加随机值，分散过期时间示例：EXPIRE key (3600 + rand(0, 600))，让缓存在 60~70 分钟内随机过期2. 核心业务缓存永不过期，由后台异步任务更新缓存

二、缓存穿透

1. 定义：

客户端请求缓存和数据库中都不存在的数据，导致请求每次都穿透缓存直达数据库，数据库反复查询不存在的数据，最终被拖垮。

2. 核心原因：

• 业务误操作：用户查询不存在的 ID（如数据库主键是 1~1000，请求 ID=9999）。
• 恶意攻击：黑客构造大量不存在的键发起请求，专门消耗数据库资源（如爬虫攻击、DDoS 变种）。

3. 典型影响

• 数据库空查询次数暴增，连接池被占满；
• 正常业务请求无法访问数据库。

4. 解决方案

1. 当数据库查询不到数据时，将该键的空结果缓存到 Redis，设置较短的过期时间（如 5 分钟）示例：SET key "" EX 300，避免相同键重复穿透2. 注意：空值缓存会占用少量内存，需控制过期时间和键数量

三、缓存击穿

1. 定义

一个热点缓存键（如秒杀商品、热门新闻）在某一时刻过期，恰好此时有大量请求访问该键，所有请求瞬间穿透到数据库，导致数据库压力骤增。

区别于雪崩：击穿是单个热点键过期，雪崩是大量键集体过期。

2. 核心原因

• 热点键过期时间设置不合理，且该键的访问量极高；
• 没有针对热点键的特殊保护机制。

3. 典型影响

• 数据库针对该热点键的查询请求瞬间暴增，短时间内压力过大；
• 可能导致数据库局部性能下降，影响其他业务。

4. 解决方案

1. 核心热点键不设置过期时间，由后台异步任务定期更新缓存数据2. 示例：秒杀商品的库存缓存，通过定时任务从数据库拉取最新库存更新 Redis

三者核心区别总结表

通用防护建议

• 监控缓存命中率、穿透率，及时发现异常；
• 缓存和数据库的部署架构要高可用，避免单点故障；
• 结合业务场景，合理选择过期策略和防护方案，不要过度设计。