Redis宕机后能否快速恢复取决于持久化方式及配置：RDB加载快但可能丢分钟级数据，AOF最多丢1秒但恢复慢，混合持久化（aof-use-rdb-preamble yes）兼顾速度与安全性，是当前生产最推荐方案。
Redis服务宕机后能否快速恢复，不取决于“有没有持久化”，而在于你用的是哪种持久化方式、配置是否匹配业务容忍度，以及启动时 Redis 实际加载了哪个文件。
RDB恢复：快但可能丢数据
RDB 是二进制快照，加载速度极快，适合对恢复时间敏感、能接受秒级到分钟级数据丢失的场景（比如缓存型会话、实时排行榜中间态）。
-
save配置项决定自动触发时机，例如save 60 10000表示 60 秒内有 10000 次写就触发一次BGSAVE；但若业务写入稀疏，两次快照间隔可能长达 15 分钟（save 900 1），宕机即丢这期间所有变更 - 恢复时 Redis 启动会自动查找
dir配置路径下的dbfilename（默认dump.rdb），只要该文件存在且校验通过，就直接 mmap 加载，通常百 MB 级数据在 100ms 内完成 - 注意：
stop-writes-on-bgsave-error yes会导致BGSAVE失败后拒绝写入，看似安全，实则可能让业务静默失败；生产环境建议设为no
AOF恢复：慢但更安全
AOF 文件是文本命令日志，重启时需逐条重放，恢复耗时明显长于 RDB，但数据丢失窗口可控（尤其 appendfsync everysec 下最多丢 1 秒）。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须显式开启：
appendonly yes，否则即使配置了appendfsync也无效 -
appendfsync always在高并发写场景下 I/O 压力极大，实测机械盘吞吐可能跌至 2000 QPS 以下；no虽快但风险不可控，云主机因系统 flush 延迟导致丢数超 30 秒并不罕见 - AOF 重写由
auto-aof-rewrite-percentage和auto-aof-rewrite-min-size共同触发，但重写过程本身也会 fork 子进程 —— 若内存达 20GB，fork 可能卡顿 300ms+，此时新写入命令会积压在 aof_rewrite_buf 中，增大恢复时需重放的指令量
混合持久化（Redis 4.0+）：兼顾速度与安全性
启用 aof-use-rdb-preamble yes 后，AOF 文件开头是 RDB 格式全量快照，后半部分是增量命令；Redis 启动时优先按混合格式解析，既避免纯 AOF 的慢加载，又比纯 RDB 少丢数据。
- 这是当前生产环境最推荐的配置，但要注意：混合 AOF 文件无法被老版本 Redis（
- 混合模式下，
redis-check-aof --fix工具不再适用，校验和修复必须用redis-check-rdb+ 手动拼接，运维复杂度上升 - 如果同时启用了 RDB 和 AOF，Redis 启动时**只加载 AOF**（无论是否混合），RDB 文件会被忽略 —— 这点常被误认为“双开更保险”，实际是冗余配置
恢复失败的常见原因和验证点
很多“恢复不了”的问题，根源不在持久化机制本身，而在文件状态或配置冲突。
- Redis 启动日志里搜
Reading RDB或Reading AOF，没看到说明压根没加载任何持久化文件；常见原因是dir路径权限不对，或dbfilename/appendfilename指向了空目录 - RDB 文件损坏时，Redis 会报错
Wrong RDB checksum并退出；可用redis-check-rdb dump.rdb快速验证，但该工具不修复，只能删掉重建 - AOF 文件末尾异常截断（如磁盘满导致 write 失败），会报
Unexpected EOF；此时不能直接redis-check-aof --fix，得先用tail -c +N appendonly.aof > fixed.aof手动截掉坏块再修复 - 从节点开启
slave-read-only yes（默认）时，即使加载了 RDB/AOF，也无法响应读请求 —— 容易误判为“恢复失败”
真正影响恢复速度的，从来不是“选 RDB 还是 AOF”，而是你是否清楚自己业务能容忍多少数据丢失、磁盘 I/O 是否撑得住同步压力、以及每次配置变更后有没有验证过启动加载路径和日志输出。这些细节，比记住参数名重要得多。
