dump.rdb是纯二进制快照文件，仅含某一时刻内存数据的紧凑编码，不含任何Redis文本协议；混合持久化下，appendonly.aof开头嵌入RDB二进制块（与dump.rdb内容一致），后续为AOF文本命令，二者角色严格分离。
dump.rdb 文件本身不会包含文本协议——这是个常见误解。当你看到混合持久化（aof-use-rdb-preamble yes 开启时）生成的 dump.rdb 文件里有类似 *2\r\n$6\r\nSELECT\r\n$1\r\n0\r\n 这样的内容，那说明你根本没在看 dump.rdb，而是在看 appendonly.aof 文件。
混合持久化下，dump.rdb 和 appendonly.aof 各自存什么？
-
dump.rdb：永远是二进制快照，由bgsave生成，结构紧凑、不可读，不包含任何 Redis 协议文本（*N\r\n/$M\r\n等）。它只记录某一时刻的完整数据状态。 -
appendonly.aof：默认是纯文本命令日志；但开启混合持久化后，它的开头部分会嵌入一个 RDB 格式快照（二进制），后面才是 AOF 文本命令。这个文件整体仍叫appendonly.aof，不是dump.rdb。
所以：
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 如果你用
cat appendonly.aof看到乱码 + 文本混杂 → 正常，这是混合 AOF 的标准格式； - 如果你用
cat dump.rdb看到可读文本 → 你可能误把 AOF 当成了 RDB，或者配置错位（比如appendfilename被改成了dump.rdb）。
为什么混合持久化要往 AOF 里塞 RDB 二进制块？
- 目的是兼顾启动速度和数据完整性：
- 先加载开头的 RDB 快照（快）；
- 再重放后续的 AOF 命令（准）；
- 这个 RDB 块是 raw binary，不是 Base64 编码，也不是文本转义 —— 它直接由
rdbSaveRio()写入，和独立dump.rdb文件内容一致，只是被拼在了 AOF 文件头部。
你可以用 redis-check-aof --fix appendonly.aof 验证：工具能识别并分离出开头的 RDB 段。
容易踩的坑
-
appendonly yes+aof-use-rdb-preamble yes启用后，dump.rdb文件依然会按 save 规则生成（除非你显式关掉 RDB）；但它和混合持久化无关，属于冗余备份。 - 不要手动修改
appendfilename指向dump.rdb—— 这会导致 AOF 写入覆盖 RDB 文件，下次重启直接报错：Wrong signature trying to load DB from file。 - 混合 AOF 文件不能用
redis-check-rdb检查（它是 AOF 格式），必须用redis-check-aof。
真正需要警惕的，是混淆文件角色：RDB 是快照，AOF 是日志，混合模式只是让 AOF “开头带个快照”，而不是让 RDB 变成文本。一旦搞反，排查方向就全偏了。
