RDB比AOF加载快得多，因其是二进制快照，可直接mmap或顺序读入内存，无需解析执行命令；而AOF需逐行读取、解析、执行，IO和CPU开销大，且文件更大、恢复更慢。
为什么 RDB 比 AOF 加载快得多
RDB 是二进制快照，Redis 启动时直接 mmap 或顺序读入内存，跳过所有命令解析和重放逻辑；AOF 则必须逐行读取、解析、执行每条命令，IO 和 CPU 开销都高得多。尤其当 AOF 文件超过几百 MB，恢复常卡在 Reading append only file... 阶段。
- 同一份数据，RDB 文件体积通常只有 AOF 的 30%–60%，磁盘寻址和加载时间显著更短
- RDB 加载是单线程批量填充，无命令执行上下文切换；AOF 恢复等价于重跑写操作，可能触发键过期、Lua 脚本、模块回调等额外开销
- Redis 7.0+ 对 RDB 加载做了零拷贝优化（
LOADING_RDB_USE_MMAP），但默认仍走常规读取；如需极致速度，得确认内核支持并启用mmap
如何确保 RDB 文件在崩溃后仍可用且加载不报错
RDB 不是“存了就一定能用”，常见失效场景是写入中途断电或磁盘满导致文件截断，Redis 启动时会校验 RDB 文件头和 CRC64 校验和，失败直接退出并打印 Wrong RDB version or checksum 或 Invalid RDB file format。
- 务必开启
save配置的双保险：例如save 60 10000+save 300 10，避免低频写入下长时间无快照 - 禁用
stop-writes-on-bgsave-error no（默认是yes），否则fork失败或磁盘满时，Redis 会拒绝写入，反而掩盖 RDB 不可用问题 - 定期用
redis-check-rdb <code>dump.rdb手动验证备份文件完整性，别只靠启动时被动检测
RDB 加载慢的三个真实瓶颈点
即使 RDB 文件本身没问题，加载仍可能慢——问题往往不在 Redis 本身，而在环境与配置。
-
vm.swappiness设为非 0 值时，Linux 可能交换部分 RDB 内存页，加载过程频繁缺页中断；生产环境建议设为1或0 - 启用了
maxmemory且接近阈值时，RDB 加载期间新键插入会触发 LRU/LFU 驱逐，大幅拖慢速度；建议加载前临时注释掉maxmemory配置 - 使用
io-threads（Redis 6.0+）对 RDB 加载无加速效果，该特性仅作用于网络 IO；加载阶段仍是单线程，别指望开多线程能提速
从生成到加载，控制 RDB 效率的关键参数
不是所有 RDB 都一样快，redis.conf 里几个参数直接影响生成质量和加载体验。
-
rdbcompression yes（默认）：用 LZF 压缩，节省磁盘但增加 CPU；若 CPU 富余、磁盘 I/O 是瓶颈，可保留；若 CPU 紧张（如容器环境），设为no反而加快生成和加载 -
rdbchecksum yes（默认）：写入末尾加 CRC64 校验和，加载时校验；如确认存储层可靠（如本地 SSD + RAID），可关掉省去一次完整扫描 -
dir和dbfilename路径必须指向高性能存储，避免放在 NFS 或低速 USB 盘上；dir /mnt/redis-data比dir /home/redis更稳妥
真正影响恢复时间的，从来不是“有没有 RDB”，而是 RDB 文件是否干净、路径是否高效、系统是否配合。磁盘 IO、内存状态、校验粒度，这些细节一松动，加载就卡住。
