Redis RDB 和 AOF 同时开启时如何选择恢复来源

Redis 同时开启 RDB 和 AOF 时，常规重启并不是让管理员手工在两个文件之间“二选一”：Redis 会优先使用 AOF 重建原来的数据集，RDB 继续承担紧凑备份和较快恢复的价值。真正需要做的判断，是 AOF 是否完整可读、允许丢失多少最近写入，以及是否还要保留 RDB 的异地备份。

先记住一句话：同时开启 RDB 与 AOF，恢复优先级通常是 AOF；RDB 是点时间快照和灾难备份。AOF 的 fsync 策略决定最近写入可能丢失多少，RDB 的快照间隔决定另一条恢复边界。

两种文件同时存在时 Redis 会优先加载什么

RDB 和 AOF 解决的是两个相邻但不同的问题。RDB 把某个时刻的内存数据集写成一个紧凑文件，例如 dump.rdb；AOF 则把改变数据集的写命令追加到日志中，Redis 启动时可以重放这些命令。

当两种持久化都启用并发生重启时，官方文档明确说明 Redis 使用 AOF 重建原始数据集，因为它通常包含更完整的最近变更。也就是说，磁盘上同时看到 dump.rdb 和 appendonlydir，不代表 Redis 会把两个文件简单合并，更不能靠删除其中一个来“选择来源”。

Redis 7 及之后的 AOF 采用多文件结构，通常由基础文件、增量文件和 manifest 共同描述一组 AOF。恢复时应把它视为一个由 Redis 管理的持久化集合，而不是只挑一个看起来最大的文件复制。若 AOF 中间出现损坏，启动日志可能要求先备份原文件，再使用 redis-check-aof 检查或修复；修复前要接受尾部数据可能被丢弃的风险。

按数据窗口和恢复速度选择 RDB 还是 AOF

“选择恢复来源”最终要落到数据窗口。RDB 的快照间隔决定故障时可能丢失的最近修改，优点是文件紧凑、适合复制到异地存储，也通常比重放大型 AOF 更快启动。AOF 可以按策略刷盘：每秒一次能把风险压到大约一秒级，每次写入都刷盘则更偏向持久性，但磁盘与延迟成本会更高。

两者同时开启也有运行成本：RDB 保存和 AOF 重写都可能 fork 后台子进程，写入密集且数据集很大时要关注内存峰值、磁盘空间和延迟。Redis 会避免让 RDB 保存与 AOF 重写同时进行，但这只能减少并发重 IO，不能替代容量规划。

重启前怎么确认恢复条件没有被旧配置覆盖

如果是从 RDB 迁移到 AOF，不建议只编辑配置后直接重启。可以在运行中的实例执行下面的检查，确认 AOF 已建立并且重写状态正常；命令只读持久化状态，不会替你修改配置。

# 查看 AOF/RDB 状态，确认重写没有进行中且最近一次重写成功
redis-cli INFO persistence | grep -E 'aof_enabled|aof_rewrite_in_progress|aof_rewrite_scheduled|aof_last_bgrewrite_status|rdb_bgsave_in_progress'

# 运行时启用 AOF 后，记得把配置写回 redis.conf 或执行 CONFIG REWRITE
redis-cli CONFIG SET appendonly yes
redis-cli CONFIG REWRITE

执行 CONFIG SET appendonly yes 会让 Redis 从当前内存数据集开始生成 AOF；但如果没有把配置持久化，下一次重启可能又回到旧的 redis.conf。重启前还要确认磁盘空间、AOF 目录中的 manifest 与相关文件可读，并记录当前 key 数量或业务侧校验值。恢复后先做只读核对，再放开写流量。

对于备份，RDB 文件在生成完成后不会被原地修改，复制已完成的快照更适合作为异地备份。AOF 备份则要考虑 Redis 7 的多文件结构和重写时机，不要在重写进行中只拷走目录里的一部分文件。

常见问题

同时开启 RDB 和 AOF，Redis 会先读 dump.rdb 吗？

常规同时开启场景下不会以 RDB 作为最终恢复来源，Redis 会使用 AOF 重建数据集。只有在明确指定预加载文件、配置改变或文件不可读等特殊场景下，才需要按实际启动配置进一步判断。

只开启 AOF 还需要保留 RDB 吗？

如果业务重视异地备份、历史时间点和较快重启，仍建议保留 RDB。AOF 更接近最近写入，不能替代所有备份策略。

appendfsync everysec 能保证一秒内绝不丢数据吗？

不能把它当成绝对保证。它表达的是每秒刷盘的策略，实际风险还受进程、操作系统、磁盘和故障类型影响；关键业务应结合复制和异地备份设计恢复方案。

AOF 损坏时能直接删除 AOF 让 Redis 读取 RDB 吗？

不要直接删除。先停止写入并备份原始 AOF，查看启动错误和文件结构，必要时使用 redis-check-aof 评估修复影响；删除 AOF 可能让最近写入永久丢失。