Redis如何应对缓存雪崩

Redis缓存雪崩的成因与总体思路
缓存雪崩通常由两类问题触发：一是大量缓存在同一时刻集中过期，二是Redis 服务不可用（宕机、网络分区等）。其结果是大量请求直接打到数据库，引发级联故障。应对思路是“预防 + 兜底”：在架构与数据层面降低同时失效的概率，在故障或失效时通过限流降级、熔断、快速恢复等手段保护后端。

预防策略

• 过期时间加随机抖动：为每个 key 的基础 TTL 增加随机值（如 0–300 秒），避免同一时间大量失效。适用于批量加载、定时刷新等场景。
• 缓存预热：在发布、大促或缓存清空后，提前将热点数据加载到 Redis，降低冷启动时的穿透与并发冲击。
• 多级缓存：结合本地内存（如 Caffeine）+ Redis + 持久层，构建分层缓存，分散单点失效风险。
• 热点数据永不过期或后台异步更新：对极热点数据可不设 TTL，由后台线程定时刷新；或在业务线程读取失败时发消息触发异步重建，避免用户线程阻塞。
• 高可用架构：部署 Redis 主从 + 哨兵 或 Redis Cluster，必要时跨机房多活，降低单节点/单机房故障的影响面。

故障与失效时的兜底

• 限流与降级：在入口（API 网关/服务层）对请求限流，对非核心数据直接降级返回默认值/静态页，保障核心链路与数据库稳定。
• 数据库熔断：当检测到数据库压力异常时快速熔断对库的访问，返回友好错误或兜底内容，待缓存恢复后再逐步放开。
• 互斥锁重建缓存：缓存未命中时仅允许一个线程去数据库加载并回写缓存，其他线程等待或快速失败，避免“缓存击穿式”的并发穿透。
• 异步刷新 + 逻辑过期：为缓存值携带逻辑过期时间，到期即触发异步重建，重建期间仍返回旧值，平滑过渡。
• 双 Key 策略：设置“主 key（有 TTL） + 备 key（无 TTL）”，主 key 失效时先返回备 key，同时后台重建主 key，降低瞬时不可用。

监控与演练

• 全链路监控与告警：对 Redis QPS、命中率、延迟、连接数 与 数据库 QPS、慢查询、连接池 建立指标与阈值告警，提前识别异常趋势。
• 故障演练与预案：定期演练 主从切换、哨兵/集群故障、缓存清空 等场景，验证限流、降级、熔断与恢复流程的有效性，并优化阈值与超时参数。

落地配置建议

• TTL 策略：基础 TTL 结合业务容忍度设置，并叠加随机抖动 5%–10%；对批量任务按 key 前缀或分片错峰过期。
• 热点数据：识别并标注热点 key，采用“永不过期 + 后台定时刷新”或“双 Key”保障可用性。
• 降级开关：为非核心接口配置静态兜底与快速失败策略，并预设熔断恢复的检查间隔与步长。
• 锁与超时：分布式锁必须设置合理超时（如 2–5 分钟），并采用唯一标识 + Lua 原子释放，避免死锁与误删。
• 异步重建：为“逻辑过期”设置刷新窗口（如 TTL 的 30%–50%），重建失败需有限重试 + 告警，避免雪崩放大。