Redis在高并发场景下如何预防缓存击穿与雪崩的双重威胁-Redis-PHP中文网

缓存击穿是单个热点key过期瞬间引发的并发穿透，需用逻辑过期+互斥锁+随机ttl避免；缓存雪崩是大批key集中过期导致的级联压垮，须打散过期时间、主动刷新并监控expired_keys；锁与降级需按场景选择，注意redis配置、主从一致性及连接池超时设置。

redis在高并发场景下如何预防缓存击穿与雪崩的双重威胁

当一个高热度 key（比如首页商品信息）恰好过期，又恰逢大量请求同时抵达，Redis 查不到，所有请求打到数据库，造成瞬时压力飙升。这不是“全量失效”，而是“单点爆破”。

关键在于：必须避免「过期时间集中 + 无兜底」的组合。常见错误是给所有同类 key 设置相同 TTL，或用 EXPIRE 手动覆盖时未加随机偏移。

对热点 key 使用逻辑过期：不依赖 Redis 自身过期机制，而是在 value 中嵌入 expireTime 字段，读取时由应用层判断是否过期；过期后加互斥锁（如 SET key value EX 30 NX）只放行一个线程回源加载，其余等待或返回旧值
避免固定 TTL：用 SETEX key <em>random_ttl</em> value，其中 random_ttl 在基础值 ±10% 范围内抖动（例如基础 300s → 270–330s）
慎用 PERSIST 或频繁 EXPIRE 覆盖——它会重置 LRU 时间戳，干扰内存淘汰策略，且无法解决初始过期洪峰

比击穿更危险的是雪崩：不是某个 key，而是成百上千个 key（比如按小时分片的报表数据）在同一分钟内集体 EXPIRED，导致数据库在短时间内被海量回源请求打满。

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

根本原因常被误认为“Redis 挂了”，其实多数情况是业务侧批量设置过期时间未做分散，或主从同步延迟导致从节点集中过期。

过期时间必须打散：同一类数据的 key 不应共用一个过期模板。例如用户画像缓存，可用 user:{id}:profile + EXPIRE user:{id}:profile (3600 + random.randint(0, 600))
主动刷新代替被动过期：对时效性要求不极端的场景（如配置类、地区列表），可启动后台任务定时 GET + SETEX 延长 TTL，把“突发回源”转为“平滑续期”
监控 expired_keys 指标：通过 INFO stats 中的该字段突增，能提前发现雪崩苗头；若配合 redis-cli --stat 观察，比等告警更及时

击穿和雪崩都可能触发回源，但“要不要锁”“锁多久”“没锁住怎么办”，得看场景。盲目上 Redlock 或全局分布式锁反而增加延迟和故障面。

单机场景优先用 SET key value EX 30 NX：原子性建锁，30 秒是合理上限（超时自动释放，避免死锁），value 推荐设为唯一请求 ID，便于排查
锁失败后别立即重试：采用指数退避（如 50ms → 100ms → 200ms）+ 最大重试 3 次，否则可能放大雪崩效应
必须配降级逻辑：锁获取失败或回源超时，应返回 cache-null（空对象缓存，TTL 缩短至 60s）或兜底静态数据，而不是抛异常或无限等待
注意 Lua 脚本的原子性边界：像“查缓存→判空→加锁→回源→写缓存”不能拆成多条命令，必须封装进一个 EVAL，否则中间状态会被其他客户端插队

很多方案在开发环境跑得通，一上生产就崩，问题往往出在和 Redis 实际运行机制的错配上。

maxmemory-policy 设为 noeviction 时，看似安全，但 OOM 后 Redis 直接拒绝写入，会导致所有缓存更新失败，加速雪崩——建议改用 allkeys-lru 或 volatile-lfu，并预留 15% 内存余量
主从架构下，slave-serve-stale-data yes 是默认开启的，但若从节点因网络延迟滞后，它返回的可能是已过期却未被清理的脏数据；此时需在客户端加一层 ttl key 校验
使用连接池时，maxWaitMillis（如 Jedis）或 socket_timeout 必须小于业务接口超时阈值，否则锁等待阻塞主线程，引发线程池耗尽——推荐设为接口超时的 1/3