一、RDB（Redis Database Backup file，数据快照）
1. 核心概念
把 Redis 某一时刻内存全部数据生成二进制快照文件存入磁盘；故障重启时加载快照恢复数据。
2. 两条核心命令
save：主进程直接执行，全程阻塞 Redis，大数据量慎用。bgsave：fork 子进程后台生成 RDB，不阻塞主进程，生产常用。
fork：复制进程页表，使用写时复制（Copy On Write）
- 读操作：父子进程共享同一块物理内存
- 主进程写数据：先拷贝这份内存页面，在新副本上修改，不影响子进程正在持久化的数据
3. 自动触发配置（redis.conf）
save 900 1 # 900s内至少1个key修改，触发bgsave
save 300 10 # 300s内至少10个key修改，触发bgsave
save 60 10000 # 60s内至少10000个key修改，触发bgsave
# save "" 代表关闭RDB持久化
rdbcompression yes # 是否开启RDB文件压缩（默认开启，消耗CPU）
dbfilename dump.rdb # RDB文件名
dir ./ # 文件存放目录4. RDB 优缺点
✅ 优点：
- 二进制文件，体积小，恢复速度快
- 适合冷备份、全量迁移 ❌ 缺点：
- 快照是间隔生成的，两次快照之间宕机会丢失这段时间所有数据
- fork 子进程时，如果数据量巨大，会产生内存开销
二、AOF（Append Only File，追加日志文件）
1. 核心概念
记录每一条写命令 （读命令不记录），以追加的方式写入日志；重启时重新执行 AOF 里所有命令恢复数据。默认关闭，appendonly yes开启。
2. 刷盘策略 appendfsync
表格
| 配置 | 刷盘时机 | 优点 | 缺点 |
|---|---|---|---|
| always | 每条写命令立刻同步刷盘 | 可靠性最高，几乎不丢数据 | 性能最差 |
| everysec（默认） | 先放缓冲区，每秒刷盘 | 性能均衡 | 宕机最多丢失 1 秒数据 |
| no | 交给操作系统自动刷盘 | 性能最好 | 不可控，可能丢大量数据 |
3. AOF 重写 bgrewriteaof
问题：同一个 key 多次修改，AOF 会保存多条命令，文件持续膨胀，比如
set num 123
set name jack
set num 666重写后，直接合并成最少命令，结果等价：
mset name jack num 666-
手动触发：
bgrewriteaof，后台子进程重写，不阻塞主进程 -
自动重写配置：
auto-aof-rewrite-percentage 100 # 文件相比上次重写后增长100%触发
auto-aof-rewrite-min-size 64mb # 文件最小达到64MB才触发重写
重写不是读取旧 AOF 文件，是读取当前内存数据直接生成最简命令。
4. AOF 优缺点
✅ 优点：
- 数据安全性更高，默认最多丢 1s 数据
- 日志可读，可人为修改修复 ❌ 缺点：
- 文件体积通常远大于 RDB
- 数据恢复时需要回放所有命令，恢复速度比 RDB 慢
三、RDB vs AOF 对比（面试高频）
表格
| 对比项 | RDB | AOF |
|---|---|---|
| 保存内容 | 某一刻内存数据快照（二进制） | 每条写命令日志 |
| 丢失数据 | 两次快照间全部丢失 | 默认最多丢失 1 秒 |
| 文件大小 | 更小 | 更大 |
| 恢复速度 | 快 | 慢 |
| 阻塞 | save 阻塞；bgsave 仅 fork 瞬间短暂阻塞 | 重写时 fork 短暂阻塞，主流程基本不阻塞 |
| 优先级 | Redis 重启时，优先加载 AOF（数据更完整） | 优先级更高 |