直接重启Redis会失败，因其默认优先加载AOF文件，若appendonly=yes且AOF存在（即使为空或损坏），则卡在LOADING状态并报“Unexpected end of file”；RDB恢复后TTL已过期，仍会击穿数据库，必须分批异步预热。
雪崩发生后不能等“系统自己缓过来”，必须人工介入抢修；核心动作只有三步：停服务、切持久化模式、分批预热，跳过任意一步都可能让数据库二次崩溃。
为什么直接重启 Redis 会失败？
因为 Redis 启动时默认优先加载 appendonly.aof，哪怕你刚放好冷备的 dump.rdb，只要配置里 appendonly yes 且 AOF 文件存在（哪怕为空或损坏），Redis 就会卡在 LOADING Redis is loading the dataset in memory 状态，日志里反复报 Unexpected end of file reading the append only file。
- 检查当前配置：
redis-cli CONFIG GET appendonly和CONFIG GET dir - 确认 AOF 文件是否存在：
ls -l $(redis-cli CONFIG GET dir | tail -1)/appendonly.aof - 别信“清空 AOF 文件就能恢复”——Redis 会拒绝加载截断的 AOF，除非临时设
aof-load-truncated yes，但这不解决根本问题
冷备 RDB 恢复的强制三步法
这不是可选项，是雪崩抢修时唯一能快速让 Redis 有数据的路径：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 先停进程：
systemctl stop redis或kill -9 $(pidof redis-server)，确保无残留子进程 - 改配置并生效：编辑
redis.conf，把appendonly yes改成appendonly no，同时确认至少有一条save规则启用（如save 900 1） - 覆盖 RDB 并校验：
cp /backup/dump.rdb $(redis-cli CONFIG GET dir | tail -1)/dump.rdb，然后chown redis:redis+chmod 644
重启后看日志是否出现 DB loaded from disk，而不是 Appended only file loaded。
RDB 加载完还是穿透 DB？因为 TTL 全过期了
RDB 恢复的是键值对，但不恢复“有效时间”——所有 key 的 TTL 在加载瞬间已过期，第一次访问仍会击穿数据库。所以 RDB 只是起点，不是终点。
- 必须立刻启动分批异步预热，严禁同步全量写入：
batch_size控在 50–200，delay_per_batch设 0.3 秒起 - 预热逻辑必须用独立线程池或 asyncio 协程，绝不能跑在 Web 请求线程里
- 每批单独 try/catch，某批失败不影响后续批次；失败后最多重试 1–2 次，避免重试风暴
最常被忽略的一点：预热期间要盯紧数据库连接数和慢查询堆积，一旦发现连接池打满或 SHOW PROCESSLIST 出现大量 Sleep 状态，立刻调小 batch_size 或拉长 delay。
