Redis通过硬编码魔数“REDIS”识别混合AOF中RDB段，匹配后切换至AOF解析模式；RDB损坏则直接报错不进入AOF阶段，且无法手动拼接或用redis-check-aof修复。
Redis启动时怎么识别混合AOF文件里的RDB和AOF部分
Redis 4.0+ 加载 aof-use-rdb-preamble yes 生成的混合AOF文件时，并不靠“解析内容”来区分前后段，而是靠**硬编码的魔数（magic）校验**。文件开头若匹配 RDB 魔数（即字节序列 52 45 44 49 53，对应 ASCII “REDIS”），就认为前半段是完整RDB二进制快照；之后所有内容则按AOF协议逐条解析命令。
这意味着：不是“先读RDB再读AOF”，而是“看到REDIS就切模式”。如果RDB部分损坏（比如截断、写入不全），Redis会在加载时报错 Wrong RDB checksum 或 Invalid RDB header，根本不会进入AOF命令解析阶段。
- 混合AOF必须以合法RDB开头——哪怕只有一字节缺失，整个加载失败
- 不能手动拼接RDB文件 + AOF文件生成混合AOF；必须由Redis自身重写（
bgrewriteaof）生成 -
redis-check-aof --fix对混合AOF无效，它只处理纯文本AOF；修复混合AOF得用redis-check-rdb配合人工截断
为什么redis-cli --rdb无法直接查看混合AOF里的RDB部分
redis-cli --rdb 是专为解析独立RDB文件设计的工具，它会尝试从文件开头完整读取RDB结构并校验EOF标记。而混合AOF中RDB部分没有自己的EOF，后面紧跟着AOF命令（以 *数字\r\n 开头），所以 redis-cli --rdb your.aof 会报错 Unexpected EOF reading RDB file 或直接卡住。
真想提取RDB部分，得先定位AOF命令起始位置：
- 用
xxd your.aof | head -20确认开头确实是REDIS - 用
redis-check-rdb --dump-header your.aof查看RDB实际长度（输出里有rdb_file_size字段） - 用
dd if=your.aof of=extracted.rdb bs=1 count=$RDB_SIZE截出RDB段，再用redis-cli --rdb extracted.rdb查看
混合AOF重写后RDB段变大，但整体文件反而更小？
这是正常现象。混合AOF重写（bgrewriteaof）时，Redis会把当前内存数据以RDB格式序列化为新快照，再把自上次重写以来的新命令追加为AOF段。RDB段变大，往往是因为：
- 内存中新增了大量键，或原有键值变大（如大字符串、哈希膨胀）
- RDB压缩被禁用（
rdbcompression no），而旧AOF里很多SET命令其实比压缩RDB更占空间 - 旧AOF里存在大量冗余操作（如对同一key反复SET/INCR），RDB只存最终状态
关键点：RDB段大小 ≠ 内存占用，它受编码方式（ziplist vs hashtable）、过期时间存储格式、是否启用LZF压缩等影响。别单看RDB段增长就怀疑异常。
加载混合AOF时卡在“Loading RDB”且CPU空转，可能是什么问题
常见于RDB段末尾与AOF段交界处存在**非法字节或未对齐填充**。Redis加载器在RDB解析完成后，会尝试读取下一个字节判断是否进入AOF模式——如果该字节是乱码、\0、或非AOF协议起始字符（如不是 *、$、+、-、:），就会反复重试、超时、最终卡死。
- 典型诱因：磁盘满导致AOF重写中途截断，RDB段完整但后续AOF数据不全
- 用
hexdump -C your.aof | tail -20查看结尾，如果最后几行全是00 00 00 ...或乱码，基本可判定 - 临时恢复方法：用
redis-check-rdb --fix尝试自动截掉损坏尾部（仅对RDB段有效），或手动用truncate -s $GOOD_SIZE your.aof
混合持久化的真正难点不在结构多复杂，而在RDB与AOF的边界极其脆弱——它不靠分隔符，只靠字节流的严格连续性。少一个字节，整个加载流程就停摆。
