RDB和AOF不能防止雪崩，仅决定宕机后数据能否快速完整恢复；RDB加载失败主因是路径、权限、版本不兼容或未启用；AOF截断需设aof-load-truncated yes临时解决；Redis优先用AOF恢复；加载后key TTL已过期，须配合缓存预热。
RDB 和 AOF 都不能单独“防止”雪崩，但能决定宕机后数据能否快速、完整地恢复——关键看你怎么配、怎么用、什么时候用。
Redis宕机后，RDB文件加载失败的常见原因
RDB 是最快恢复方式，但不是“放进去就能用”。常见加载失败不是文件损坏，而是路径或权限问题：
-
dump.rdb文件不在dir配置指定的目录下（比如你手动拷贝到了/tmp/，但redis.conf里dir /var/lib/redis） - Redis 进程用户（如
redis用户）对dump.rdb文件没有读权限（chmod 644 dump.rdb通常就够） - 文件版本不兼容：比如用 Redis 7.2 生成的 RDB 被 6.2 版本尝试加载（报错类似
Wrong RDB version） - 启动时未启用 RDB：配置中
save ""或注释了所有save规则，导致 Redis 启动时不检查dump.rdb
AOF重写后无法加载？检查 appendfsync 和 aof-load-truncated
AOF 恢复比 RDB 更慢，但更安全；但若进程异常退出，AOF 文件末尾可能截断。Redis 默认会拒绝加载这种文件：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 错误现象：
Unexpected end of file reading the append only file - 临时解决：在
redis.conf中设置aof-load-truncated yes（仅限恢复阶段，非长期方案） - 根本规避：把
appendfsync从no改为everysec——no看似性能好，但宕机后 AOF 几乎必然丢失最后几秒甚至几分钟数据，且更容易出现截断 - AOF 重写（
bgrewriteaof）期间若磁盘满，也会产生坏文件；建议监控aof_current_size和aof_base_size指标，提前扩容
同时开启 RDB + AOF 时，Redis 优先用哪个恢复？
Redis 重启时会自动判断：只要 appendonly.aof 文件存在且校验通过，就只用 AOF 恢复，完全忽略 dump.rdb。
- 这是硬编码逻辑，无法通过配置绕过
- 好处：AOF 数据更新更全（RDB 总是滞后最后一次快照）
- 风险：如果 AOF 文件大（比如几十 GB）、校验慢，启动时间可能长达数分钟；而 RDB 加载通常秒级
- 应急建议：雪崩刚发生、急需抢修时，可临时 rename 掉
appendonly.aof，让 Redis 退回到 RDB 恢复模式，等服务起来再补同步
持久化不是万能的——雪崩恢复还卡在“冷启动”上
哪怕 RDB/AOF 加载成功，Redis 内存里有了旧数据，请求进来依然可能打穿数据库。因为雪崩本质是“缓存集体失效”，不是“Redis没数据”：
- 加载的只是键值对，但 TTL 已过期——这些 key 在加载后立刻被标记为“已过期”，下次访问仍会穿透
- 真正要的是“有效缓存”，不是“历史缓存”。所以必须配合预热：比如用脚本批量
EXPIRE延长热点 key 的 TTL，或触发业务侧异步重建 - 本地缓存（如 Caffeine、Ehcache）在此刻比 Redis 持久化更重要——它不依赖网络和外部服务，能扛住第一波穿透流量
最常被忽略的一点：RDB/AOF 解决的是“Redis 进程挂了之后数据还在不在”，而不是“雪崩发生时请求怎么不压垮 DB”。后者靠的是过期时间随机化、多级缓存、熔断降级——持久化只是兜底链条的最后一环，别把它当主力防线。
