RDB：快照 ；AOF：日志追加，是 Redis 两种持久化方案，可同时开启。
一、RDB（Redis DataBase）
原理 ：在指定时间点，把内存中全量数据生成二进制快照文件 dump.rdb，保存到磁盘。 触发方式：
- 自动：
save m n配置，m 秒内至少 n 次修改，自动 bgsave - 手动：
SAVE（主进程阻塞） /BGSAVE（fork 子进程，不阻塞主线程） - 执行
shutdown默认触发 RDB
✅ 优点
- 文件体积小，二进制压缩，适合备份、灾备、全量迁移
- 恢复速度极快，直接加载二进制文件
- 对 Redis 主线程影响小（BGSAVE 用子进程写）
❌ 缺点
- 会丢数据：两次快照之间的数据如果宕机，这部分数据丢失
- fork 子进程时，内存量大时会短暂阻塞（拷贝页表，内存越大阻塞越明显）
- 大数据集时，bgsave 比较消耗 CPU
二、AOF（Append Only File）
原理 ：记录每一条写命令 ，追加写入 aof 文件（appendonly.aof），重启时重放命令恢复数据。 写策略 appendfsync：
always：每写一条就刷盘，几乎不丢数据，性能最差everysec（默认）：每秒刷一次，最多丢失 1 秒数据，性能均衡no：交给操作系统自动刷，性能最好，丢数据不可控
AOF 重写（bgrewriteaof）： AOF 文件会越来越大，重写会在子进程里根据当前内存数据，生成精简命令集，去掉冗余命令（多次修改同一个 key 只保留最后结果），生成新 aof 文件替换旧文件，不会阻塞主线程。
✅ 优点
- 数据安全性高，默认最多丢 1s 数据；always 几乎零丢失
- 日志可读，误操作可以人工修复 aof 文件
❌ 缺点
- 文件体积通常比 RDB 大很多
- 恢复速度比 RDB 慢（需要逐条执行命令）
- 持续刷盘，性能略低于 RDB
三、两者同时开启（生产推荐）
Redis 重启加载优先级：AOF > RDB
- 同时开启：用 AOF 保证数据少丢失，RDB 做冷备份
- 故障恢复优先加载 AOF；AOF 损坏无法读取，才会尝试加载 RDB 快照
四、核心对比表
| 维度 | RDB | AOF |
|---|---|---|
| 本质 | 全量二进制快照 | 写命令追加日志 |
| 数据丢失 | 可能丢失上次快照之后所有数据 | everysec 最多丢 1s，always 几乎不丢 |
| 文件大小 | 小，压缩二进制 | 大，保存命令 |
| 恢复速度 | 快 | 慢 |
| 性能 | 高，fork 开销 | 略低，刷磁盘开销 |
| 阻塞 | BGSAVE fork 瞬间短暂阻塞 | 一般不阻塞；重写 fork 也有短暂阻塞 |
| 可读性 | 二进制不可读 | 文本命令，可读 |
五、扩展问题
- RDB 的 bgsave 为什么用 fork？ fork 创建子进程，父子进程共享内存页，写时复制 COW。子进程遍历内存生成快照，主线程继续处理请求。
- AOF 重写会不会阻塞主线程？ bgrewriteaof 是 fork 子进程执行，主线程不阻塞；fork 瞬间有短暂阻塞。重写过程中新命令依然追加到老 AOF。
- RDB 和 AOF 选型？
- 能接受分钟级少量丢数据，做备份：RDB
- 要求尽量少丢数据：AOF everysec
- 生产：同时开启，AOF 为主恢复，RDB 作为定期冷备