Redis雪崩发生后必须三步应急：第一步熔断限流挡穿透请求，第二步据RDB/AOF判断快速恢复，第三步预热+随机TTL防二次雪崩。
Redis 雪崩发生后，不能等它“自己缓过来”——必须立刻切断穿透流量、抢修缓存层、兜住数据库，三步内控制住局面。
第一步：立即熔断+限流，挡住穿透请求
雪崩的本质是海量请求瞬间击穿缓存直打数据库，所以第一反应不是修 Redis，而是让数据库“喘口气”。
- 在网关（如 Nginx、Spring Cloud Gateway）或服务入口层，对高频缓存依赖接口（如
/api/product/{id}、/api/user/profile）紧急开启限流，例如限制单 IP 每秒 ≤5 次，或全局 QPS ≤1000 - 对已确认雪崩的业务模块，启用降级开关（如配置中心下发
cache.fallback.enabled=true），直接返回兜底数据（如默认商品图、空用户信息），避免查库 - 若已有熔断组件（如 Sentinel、Resilience4j），检查
redis.get调用链是否已触发熔断；没触发就手动强制打开，防止下游数据库被拖垮
第二步：判断 Redis 是否可恢复，决定走 RDB 还是 AOF
别一上来就 redis-server redis.conf 重启——得先看持久化文件能不能用、要不要绕过。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 检查
redis.conf中dir路径下是否存在dump.rdb，且 Redis 进程用户（如redis）有读权限：ls -l /var/lib/redis/dump.rdb - 如果 AOF 文件（
appendonly.aof）存在但报错Unexpected end of file reading the append only file，临时在配置中加aof-load-truncated yes，再启动；长期必须切回appendfsync everysec - 同时存在 RDB 和 AOF 时，Redis 默认只加载 AOF——若 AOF 文件超大（比如 >20GB），启动慢，可先
mv appendonly.aof appendonly.aof.bak，强制退回到 RDB 快速拉起服务
第三步：恢复后必须补做两件事，否则 5 分钟内可能二次雪崩
Redis 进程起来了、key 也加载进去了，不等于问题结束。刚加载的 key 全是“僵尸状态”——TTL 已过期，第一次访问照样穿透。
- 启动后立刻执行缓存预热：用脚本批量调用核心接口（如
GET /api/product/list?size=100），或从数据库导出热点 key 列表，用redis-cli --pipe批量写入并设置新 TTL - 检查所有写缓存逻辑，确认是否已加入随机偏移：比如原
SET product:123 "xxx" EX 7200，现在必须改成EX 7200 + rand(600..1800)，否则下次大促凌晨两点还是全崩 - 验证互斥锁是否生效：模拟一个失效 key，观察是否只有一个线程去查库重建缓存，其余请求是否等待或返回兜底值；重点看
SET key value EX 30 NX的原子写锁逻辑有没有超时和释放遗漏
最常被跳过的环节是预热和 TTL 随机化——很多人看到 Redis 进程起来了、监控绿了，就以为恢复完成。其实这时候缓存层只是“有形无神”，真正的压力正悄悄压向数据库。雪崩恢复不是“服务起来”，而是“请求不再穿透”。
