Redis缓存雪崩后，如何进行全量缓存数据恢复？-Redis-PHP中文网

redis启动时强制用rdb恢复需先停服务，重命名或移除appendonly.aof文件，再启动；因默认优先加载aof，存在即忽略rdb，且rdb加载后key ttl已过期，需配合异步分批预热与熔断机制。

redis缓存雪崩后，如何进行全量缓存数据恢复？

雪崩后不能直接全量回填 Redis，否则数据库会二次崩溃——必须分批异步预热，且要配合持久化文件加载与 TTL 重设。

雪崩常伴随 Redis 全节点宕机，此时若同时启用了 AOF 和 RDB，Redis 默认只认 appendonly.aof；哪怕你放好了 dump.rdb，它也会忽略并新建一个空 AOF 文件。

临时方案：停服务后，先重命名或移走 appendonly.aof（如 mv appendonly.aof appendonly.aof.bak），再启动 Redis —— 它会 fallback 到 RDB 加载
配置确认：检查 redis.conf 中 appendonly no 是否生效；若已启用 AOF，仅靠改配置不生效，必须删/重命名文件
风险提示：RDB 加载后所有 key 的 TTL 已过期，KEYS * 能查到，但 TTL keyname 返回 -2 或 -1，访问仍穿透 DB

同步写入 10 万 key = 10 万次 DB 查询 + 10 万次 redis.set()，而雪崩后的数据库连接池往往已耗尽、慢查询堆积。主请求线程卡住会导致超时级联，甚至触发网关重试风暴。

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

下载

batch_preload() 必须脱离 Web 请求生命周期，用 ThreadPoolExecutor 或 asyncio.to_thread() 隔离
每批次控制在 batch_size=50–200，取决于单条 SQL 平均耗时（建议先压测 100 条的 DB 响应 P95
批次间 await asyncio.sleep(0.3) 不是“限流”，是给数据库连接池回收空闲连接、刷慢查询日志留出时间窗口

RDB 加载后 key 存在但 TTL 失效，直接 SET 会覆盖旧值却没设新过期时间，导致缓存永久有效或立即失效。必须显式重设 TTL。

读 DB 后写入 Redis 时，统一用 redis.setex(key, ttl_seconds, value) 或 redis.set(key, value, ex=ttl_seconds)
不要依赖“原样恢复 RDB”，RDB 中的过期时间只是快照时刻的状态，不是业务需要的缓存策略
若部分 key 需永不过期（如配置类），单独标记处理，避免和普通业务 key 混用同一套预热逻辑

光看 Redis 写入 QPS 没用，真正的瓶颈在数据库侧。预热过程中必须盯紧三个实时指标：

数据库连接数：show status like 'Threads_connected'，持续 > 连接池上限 80% 就该降速
Redis latency：用 redis-cli --latency 观察 P99 延迟是否突增 > 50ms
错误率：redis.exceptions.TimeoutError 或 DB 层 OperationalError: (2003, "Can't connect to MySQL server") 出现即熔断

最易被忽略的是：预热脚本里没加熔断，发现异常后仍继续发 batch，等于主动制造第三次雪崩。