缓存击穿是单个热点key过期瞬间引发的并发穿透，需用逻辑过期+互斥锁+随机TTL避免；缓存雪崩是大批key集中过期导致的级联压垮，须打散过期时间、主动刷新并监控expired_keys；锁与降级需按场景选择，注意Redis配置、主从一致性及连接池超时设置。
缓存击穿：单个热点 key 过期瞬间的并发穿透
当一个高热度 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，而是成百上千个 key（比如按小时分片的报表数据）在同一分钟内集体 EXPIRED，导致数据库在短时间内被海量回源请求打满。
Redis Skill - 高性能缓存管理
下载
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
