rdb是某时刻内存快照，aof是命令日志流，二者结构与语义不同，无法直接比对；应验证文件完整性并加载测试，以业务数据状态为准判断恢复效果。
Redis宕机后，RDB 和 AOF 文件可能各自反映不同时间点的状态，直接比对二者内容无法得出“谁更准”，因为它们本就不承诺逻辑一致——RDB 是某个时刻的快照，AOF 是从某个起点开始的命令流。真正要做的，不是比对两个文件是否“长得一样”，而是确认**哪个文件能恢复出你期望的数据状态**。
为什么不能直接 diff dump.rdb 和 appendonly.aof
RDB 是二进制格式，AOF 是纯文本命令日志，二者结构完全不同，强行用 diff 或哈希比对毫无意义。更关键的是：
-
RDB文件只包含 fork 时刻的内存快照，之后所有写入都不在其中； -
AOF文件记录的是命令，但若启用了appendfsync everysec，最后最多 1 秒的命令可能还没落盘； - 如果开启了混合持久化（
aof-use-rdb-preamble yes），AOF文件开头是 RDB 格式块，后面才是 AOF 命令——此时它既不是纯 RDB，也不是纯 AOF。
实际恢复前该检查什么
重点不是“比对”，而是验证每个持久化文件是否可加载、是否完整、是否覆盖你需要的数据范围：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
redis-check-rdb dump.rdb检查 RDB 文件是否损坏，输出应含Checksum OK； - 用
redis-check-aof --fix appendonly.aof尝试修复 AOF（即使没报错也建议跑一遍，它会自动截断未完成的最后一条命令）； - 临时启动一个隔离 Redis 实例（指定不同
port和dir），仅加载RDB，执行redis-cli -p 6380 keys "*"+info memory记下 key 数量和内存占用； - 再换一个端口，关闭
RDB、仅开启AOF，重复上述步骤； - 若两者 key 数量差异明显，说明最后一次 AOF 写入与 RDB 快照之间存在显著数据偏移——这时应以业务写入时间线为准，而非文件本身。
如何定位“最后有效写入”时间点
Redis 自身不记录每条命令的时间戳，但你可以借助外部手段缩小窗口：
- 查 Redis 日志（如果启用了
loglevel verbose或debug）：搜索Background saving started找到最近一次bgsave时间，再搜Writing 1000000000 bytes to AOF类似行定位 AOF 刷盘动作； - 若应用层有写操作日志（比如用
SET前打点），对比宕机时间与最后成功写入时间； - 注意：
INFO persistence中的rdb_last_save_time和aof_last_rewrite_time是进程内记录，若 Redis 异常退出，这些字段可能未更新，不可全信。
混合模式下优先加载哪个文件
Redis 4.0+ 启用 aof-use-rdb-preamble yes 后，启动时会自动忽略 RDB 文件，只加载 AOF ——因为该 AOF 文件已内嵌最新 RDB 快照。此时：
- 不要手动删掉
AOF去“退回到 RDB”； - 若怀疑 AOF 损坏，先用
redis-check-aof --fix修复，再启动； - 修复后仍数据异常？可临时注释掉
appendonly yes并取消aof-use-rdb-preamble，强制走纯 RDB 恢复，但这会丢失 AOF 中的增量部分——必须权衡。
真正容易被忽略的一点：RDB 和 AOF 的“一致性”不是文件层面的字节匹配，而是业务语义层面的可用性。哪怕两个文件都能成功加载，若其中某个漏掉了关键 key 的 EXPIRE 设置或 HSET 的某个 field，对业务的影响可能远大于丢几条日志。所以比对动作一定要落到具体 key 和 value 上，而不是停留在文件校验环节。
