因为redis启动时优先加载aof文件，若appendonly yes开启且appendonly.aof存在（即使为空），则跳过dump.rdb直接回放aof，导致数据为空。
为什么直接替换 dump.rdb 后 Redis 还是空的？
因为 Redis 启动时优先加载 appendonly.aof，哪怕你刚放好 dump.rdb，只要配置里 appendonly yes 开着，且 appendonly.aof 文件存在（哪怕为空、损坏或 0 字节），Redis 就会跳过 RDB，尝试回放 AOF —— 而雪崩后这个文件往往无效，结果内存加载完仍是空的。
常见错误现象：LOADING Redis is loading the dataset in memory 卡住几分钟；redis-cli INFO persistence 显示 aof_enabled:1 但 aof_current_size:0；应用层持续报 Connection refused 或 DB 穿透。
- 先确认当前持久化方式：
redis-cli CONFIG GET appendonly和CONFIG GET save - 检查 AOF 文件是否存在：
ls -l $(redis-cli CONFIG GET dir | tail -n 1)/appendonly.aof - 别试图“清空 AOF”来解决——删内容没用，必须让 Redis 彻底不走 AOF 加载路径
冷备 RDB 恢复必须执行的三步强制流程
这不是可选建议，而是雪崩抢修时唯一可靠的最小可行路径。跳过任意一步，大概率失败。
- 停掉 Redis 进程：
systemctl stop redis或kill -9 $(pidof redis-server)（确保无残留进程） - 关 AOF 并启用 RDB：编辑
redis.conf，把appendonly yes改成appendonly no；同时确认至少有一条save规则启用（如save 900 1），否则启动后仍不加载dump.rdb - 复制冷备文件：
cp /backup/dump.rdb $(redis-cli CONFIG GET dir | tail -n 1)/dump.rdb，然后chown redis:redis且chmod 644
重启后盯日志：journalctl -u redis -f，看到 DB loaded from disk 才算成功；若出现 Appended only file loaded，说明 AOF 还在生效，流程没走完。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
redis-cli CONFIG SET appendonly no 为什么不能替代改配置文件？
这条命令确实能运行时关闭 AOF，但它只影响当前实例的运行态，不影响 Redis 启动时的加载逻辑。Redis 启动第一件事就是读配置文件，判断要不要加载 AOF —— 只要配置里还是 appendonly yes，哪怕你之前用 CONFIG SET 关过，它照样去找 appendonly.aof。
-
CONFIG SET是热修改，适合日常调参，但对恢复流程无效 - 必须改
redis.conf并确保重启时生效；改完建议用redis-cli CONFIG REWRITE同步到配置文件（如果支持） - 某些容器化部署中，conf 是挂载的 ConfigMap，需同步更新并触发 rollout，不能只改容器内文件
恢复后 key 全部过期，为什么缓存还是穿透？
RDB/AOF 恢复的是“历史快照”，不是“有效缓存”。所有 key 的 TTL 在加载时就已过期，Redis 不会主动刷新它们的过期时间 —— 下次 GET 就直接判定为 miss，请求立刻打穿 DB。
- 不要指望恢复完就万事大吉；必须配套做缓存预热：用脚本批量
SET ... EX重设 TTL，或触发核心接口主动加载 - 错峰过期很重要：避免所有 key 设置相同
EX值，应加随机偏移（如EX 3600 + rand(300)） - 降级开关得提前准备好：一旦发现
redis-cli INFO keyspace显示expires=0，立刻切 fallback，别等 DB 报警
真正卡点不在“数据有没有”，而在“数据有没有效”。雪崩恢复的终点不是 Redis 启动成功，是第一个有效缓存命中。
