rdb加载比aof快，因其是二进制快照，仅需反序列化+字典插入；aof是文本命令流，须逐条执行完整命令流程，路径更长、开销更大。
为什么RDB加载比AOF快：二进制快照 vs 文本命令重放
RDB加载快的根本原因不是“文件小”，而是加载过程完全跳过了命令解析与执行环节。RDB文件是某一时刻内存数据的**直接序列化映像**，Redis启动时只需将二进制块按结构反序列化进内存；而AOF必须逐行读取文本、解析协议（如*3\r\n$3\r\nset\r\n$7\r\ntestkey\r\n$9\r\ntestvalue\r\n）、校验语法、再调用对应命令逻辑执行——这本质是一次完整的“重放”，开销远高于内存拷贝。
RDB加载不涉及命令执行，AOF加载本质是replay
AOF恢复等价于把整个写操作历史重新跑一遍：每条set、lpush、incr都要走完整命令生命周期（解析→校验→执行→响应模拟），哪怕中间有大量冗余操作（比如对同一key反复set）。RDB则没有这个过程——它记录的是最终状态，不是过程。例如，AOF里可能有100条incr counter，恢复时要执行100次；RDB里只存counter: 100这一条键值对，直接载入即可。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- RDB加载：解包 → 分配内存 → 填充结构体 → 完成
- AOF加载：逐行读取 → 协议解析（
*N、$M）→ 构建命令对象 → 调用call()→ 执行回调 → 更新数据库 - 即使启用
aof-rewrite压缩，重写后的AOF仍是命令流，仍需逐条执行，无法跳过解析环节
二进制格式带来两个关键优势：紧凑性 + 零解析开销
RDB用自定义二进制编码（非JSON/Protobuf），字段长度、类型、过期时间都以固定字节紧凑排列。比如一个带过期时间的字符串键，在RDB中可能是：REDIS_RDB_TYPE_STRING（1字节） + 过期时间戳（8字节） + 字符串长度（可变长整数） + 原始字节流。这种格式CPU可直接memcpy+指针偏移访问，无需tokenize或状态机解析。
- AOF每条命令至少包含协议头（
*N\r\n）、参数头（$M\r\n）、换行符（\r\n），纯文本体积大，IO压力高 - RDB默认启用
rdbcompression yes（LZF压缩），进一步减少磁盘读取量；AOF文本几乎无法有效压缩 - 大key场景下差异更明显：一个10MB的
hash，RDB序列化后可能仅2MB；AOF会记录上百条hset命令，文本体积常超15MB，且解析耗时线性增长
容易被忽略的细节：AOF重写不改变加载机制
很多人误以为bgrewriteaof生成的AOF“更高效”，其实它只是合并了冗余命令（如把100次hset user:name缩为1次hmset user name），但依然输出文本协议格式，加载时仍要走完整命令解析链路。RDB的快，是架构层面的不可替代性——它绕开了Redis命令执行引擎本身。这也是为什么混合持久化（aof-use-rdb-preamble yes）会在AOF开头嵌入一段RDB二进制数据：先快速载入主体状态，再回放末尾增量命令，折中兼顾速度与安全性。
