Redis启动时优先加载appendonly.aof文件，即使dump.rdb存在且完好，只要AOF启用且文件存在（哪怕为空或损坏），就会忽略RDB并尝试回放AOF；若AOF无效，内存仍为空。
RDB 冷备文件能直接用于雪崩恢复，但必须关掉 AOF 才生效；热备（主从+哨兵）本身不防雪崩，只防节点宕机。
为什么直接替换 dump.rdb 后 Redis 还是空的？
因为 Redis 启动时优先加载 appendonly.aof，哪怕你放好了 dump.rdb，只要 appendonly yes 开着，且 appendonly.aof 文件存在（哪怕为空或损坏），Redis 就会尝试回放 AOF —— 而雪崩场景下 AOF 往往是空的或过期指令，结果就是加载完内存仍是空的。
常见错误现象：LOADING Redis is loading the dataset in memory 持续数分钟，应用层持续报 Connection refused 或大量 DB 穿透；redis-cli INFO persistence 显示 aof_enabled:1 但 aof_current_size:0。
- 检查当前持久化方式：
redis-cli CONFIG GET appendonly和CONFIG GET save - 确认 AOF 文件是否存在：
ls -l /var/lib/redis/appendonly.aof（路径以CONFIG GET dir为准） - 若 AOF 存在但无有效内容，不能靠“清空 AOF”解决，必须停用 AOF 加载逻辑
冷备 RDB 恢复的三步强制流程
这不是“推荐做法”，而是雪崩后抢修时的最小可行路径。跳过任何一步都可能失败。
- 停 Redis 进程：
systemctl stop redis或kill -9 $(pidof redis-server)（确保无残留） - 关闭 AOF 并指定 RDB 路径：
redis-cli CONFIG SET appendonly no→ 立即生效，但仅对运行中实例；真正起作用的是修改配置文件中的appendonly no，并确认save规则已启用（如save 900 1） - 把冷备
dump.rdb复制到dir目录（CONFIG GET dir查），覆盖原文件，权限设为redis:redis，644 - 重启 Redis：
systemctl start redis；观察日志是否出现DB loaded from disk而非Appended only file loaded
热备（主从+哨兵）在雪崩中到底起什么作用？
它完全不缓解雪崩，反而可能放大问题：新选出来的主节点，缓存仍是空的，TTL 全过期，请求照穿 DB。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
真实限制：
- 哨兵 failover 平均耗时 2–10 秒，期间客户端若没配重试，直接报错，不是静默等待
- 从节点同步延迟大时（如
slave_repl_offset落后主节点 >5 秒），你看到的“有数据”其实是旧快照，降级决策会失效 - 主从切换后，所有 key 的 TTL 时间戳仍按原始过期时间计算 —— 冷备恢复的 RDB 里，这些时间戳早已过期，Redis 加载后立刻标记为 expired，GET 时返回 nil 并穿透
所以，热备只是让“谁来当主”更可靠，不是让“主里有没有缓存”更可靠。
恢复后必须立即做的两件事
否则 5 分钟内可能再次雪崩。
- 给存量 key 补 TTL：
redis-cli --scan --pattern '*' | xargs -I {} redis-cli EXPIRE {} 3600（慎用，先在小范围测试）；更安全的做法是用脚本遍历 key，跳过已有 TTL 的 key - 切走流量前，用本地缓存（如 Caffeine）或内存常量做 fallback，开关必须运行时可调（例如
SET degrade:search 1 EX 300），避免一上来就全量查 DB
最易被忽略的一点：RDB 文件里存的是“键值+绝对过期时间戳”，不是“相对 TTL”。雪崩恢复后，即使你刚从 2 小时前的备份加载，那些 key 的过期时间也还是 2 小时前设的——它们在加载瞬间就已过期。不重设，等于没恢复缓存。
