一、核心概念
Redis 提供了三种持久化机制，用于将内存数据持久化到磁盘，防止数据丢失：
- RDB（Redis Database）：快照持久化
- AOF（Append Only File）：追加日志持久化
- 混合持久化（RDB + AOF）：Redis 4.0 后引入
二、详细原理
1. RDB 快照持久化
工作原理：
- 在指定时间间隔内，将内存中的数据集快照写入磁盘
- 生成一个经过压缩的二进制文件
dump.rdb - 使用
fork()创建子进程，采用 COW（Copy-On-Write） 机制
触发方式：
- 手动触发：
SAVE（阻塞）、BGSAVE（后台异步） - 自动触发：配置
save <seconds> <changes>，例如save 900 1
配置示例：
# 900秒内至少1个key被修改，触发RDB
save 900 1
save 300 10
save 60 10000
# RDB文件名
dbfilename dump.rdb
# 存储目录
dir /var/lib/redis
优点：
- 适合大规模数据恢复，恢复速度快
- 对性能影响小（子进程完成）
- 文件紧凑，便于备份和传输
缺点：
- 数据完整性较差，可能丢失最后一次快照后的数据
fork()子进程时，数据集大时会有瞬时性能影响
2. AOF 追加日志持久化
工作原理：
- 以日志形式记录每个写操作命令（读操作不记录）
- 追加到
appendonly.aof文件末尾 - Redis 重启时，重新执行 AOF 文件中的命令恢复数据
刷盘策略（fsync）：
- always：每次写操作都刷盘（安全但慢）
- everysec：每秒刷盘一次（默认，折中方案）
- no：由操作系统决定（性能最好但可能丢失较多数据）
配置示例：
# 开启AOF
appendonly yes
# AOF文件名
appendfilename "appendonly.aof"
# 刷盘策略
appendfsync everysec
# AOF重写配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
AOF 重写机制：
- AOF 文件会不断增大，Redis 提供 AOF 重写 功能压缩文件
- 重写时，直接读取当前内存数据状态生成新 AOF 文件
- 命令：
BGREWRITEAOF
优点：
- 数据完整性高，最多丢失 1 秒数据（everysec）
- 日志文件可读，便于分析和修复
缺点：
- AOF 文件通常比 RDB 文件大
- 恢复速度比 RDB 慢
- 写入性能略低于 RDB
3. 混合持久化（RDB + AOF）
工作原理（Redis 4.0+）：
- AOF 重写时，将重写时刻的内存快照以 RDB 格式 写入 AOF 文件头部
- 增量数据以 AOF 格式 追加到文件尾部
- 结合了 RDB 的快速恢复和 AOF 的数据完整性
配置：
# 开启混合持久化（Redis 4.0+）
aof-use-rdb-preamble yes
优点：
- 恢复速度快（RDB 部分直接加载）
- 数据完整性高（AOF 部分补充增量）
三、对比总结
| 特性 | RDB | AOF | 混合持久化 |
|---|---|---|---|
| 文件大小 | 小（压缩） | 大 | 中等 |
| 恢复速度 | 快 | 慢 | 快 |
| 数据完整性 | 差（可能丢失几分钟数据） | 好（最多丢失1秒） | 好 |
| 性能影响 | 小 | 中 | 中 |
| 适用场景 | 备份、全量复制 | 对数据完整性要求高 | 生产环境推荐 |
四、生产环境最佳实践
- 推荐配置：开启 AOF + 混合持久化
appendonly yes appendfsync everysec aof-use-rdb-preamble yes - 同时使用 RDB 和 AOF：
- RDB 用于定期备份
- AOF 用于数据恢复
- Redis 重启时，优先使用 AOF 文件恢复
- 关键配置建议：
- 生产环境避免使用
SAVE（阻塞主进程） - AOF 刷盘策略推荐
everysec（性能与安全平衡） - 定期备份 RDB 文件到远程存储
- 生产环境避免使用
- 高可用场景：
- 配合 Redis 主从复制、哨兵或集群
- 持久化只在从节点开启，降低主节点压力
五、面试答题要点
- 快速回答：Redis 有 RDB、AOF 和混合持久化三种机制
- RDB：全量快照，适合备份，恢复快但可能丢数据
- AOF：记录写命令，数据完整性高但文件大、恢复慢
- 混合持久化：结合两者优点，生产环境推荐
- 注意点：同时开启时，Redis 优先使用 AOF 恢复数据