Redis 持久化 RDB、AOF：从原理到混合模式，一篇讲透
面试官：“Redis 如何保证数据不丢失？”
你：“Redis 提供两种持久化方式：RDB 快照和 AOF 日志。RDB 生成二进制快照，恢复快但可能丢数据；AOF 记录写命令，数据更安全但文件大。生产环境通常开启混合持久化，兼具两者优点。”
面试官：“那混合持久化具体是怎么工作的？AOF 重写的过程是怎样的？”
你：“……”
很多人能说出 RDB 和 AOF 的区别，但一追问底层实现、重写机制、混合模式原理就含糊了。本文从源码角度，彻底讲透 Redis 持久化机制，并给出生产环境的最佳配置。
一、为什么需要持久化？
Redis 是内存数据库，所有数据存储在内存中，一旦进程退出（宕机、重启），数据就会丢失。持久化就是将内存中的数据保存到磁盘，以便重启后能够恢复。
Redis 提供了两种持久化方式：
- RDB（Redis Database）：在指定时间间隔内生成内存快照。
- AOF（Append Only File）：记录每个写操作命令，重启时重放。
生产环境中，通常使用RDB + AOF 混合模式（Redis 4.0 引入），兼顾数据安全与恢复速度。
二、RDB（快照持久化）
1. 原理
RDB 将某个时间点的内存数据以二进制压缩形式写入磁盘文件（dump.rdb）。生成方式有两种：
- 手动触发：执行
SAVE（阻塞主进程）或BGSAVE（fork 子进程异步保存）。 - 自动触发：根据
save配置定时执行，例如save 900 1（900 秒内至少 1 次修改则 BGSAVE）。
BGSAVE利用Copy-on-Write（COW）技术：主进程 fork 子进程，子进程共享父进程的内存页表，然后子进程将数据写入临时 RDB 文件，完成后替换旧文件。期间主进程仍可处理请求，但若有写操作，操作系统会复制被修改的内存页，导致内存占用升高。
2. RDB 配置
# 触发条件：时间/修改次数 save 900 1 save 300 10 save 60 10000 # RDB 文件名 dbfilename dump.rdb # 文件存储路径 dir /var/lib/redis # 是否压缩（LZF 算法），节省磁盘但消耗 CPU rdbcompression yes # 是否开启 CRC64 校验，保证文件完整性 rdbchecksum yes3. RDB 优点
- 恢复速度快：直接加载二进制数据到内存，比 AOF 重放快得多。
- 文件紧凑：二进制压缩，适合备份、异地容灾。
- 对性能影响小：fork 子进程后，主进程继续处理请求（COW 机制）。
4. RDB 缺点
- 可能丢失数据：两次快照之间的修改会丢失。例如每 5 分钟 save，若宕机则丢失最近 5 分钟数据。
- fork 开销：当内存很大时（数十 GB），fork 子进程会耗时较长，且 COW 可能导致内存占用翻倍。
- 无法实时持久化：不适合对数据安全性要求极高的场景。
三、AOF（追加日志持久化）
1. 原理
AOF 以文本格式记录每个写操作命令（如SET key value），追加到appendonly.aof文件中。Redis 重启时，重新执行 AOF 文件中的所有命令来恢复数据。
写入流程：
- 执行写命令。
- 将命令追加到 AOF 缓冲区（内存）。
- 根据
appendfsync策略将缓冲区刷入磁盘：always：每次写命令后立即 fsync，最安全但最慢。everysec：每秒 fsync 一次（默认），最多丢失 1 秒数据，兼顾性能与安全。no：由操作系统决定刷盘时机，性能最好但可能丢失较多数据。
2. AOF 重写（Rewrite）
随着写操作增多，AOF 文件会无限膨胀。Redis 通过AOF 重写将其压缩：创建一个子进程读取当前内存数据，生成最少的命令集（相当于FLUSHALL再重新 SET），然后替换旧 AOF 文件。重写期间，主进程仍可处理请求，新命令会写入重写缓冲区，待子进程完成后追加到新 AOF 文件末尾。
3. AOF 配置
# 开启 AOF appendonly yes # 文件名 appendfilename "appendonly.aof" # 同步策略 appendfsync everysec # 自动重写条件：文件增长比例和最小大小 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # 重写期间是否执行 fsync no-appendfsync-on-rewrite no # 加载 AOF 时遇到错误是否继续 aof-load-truncated yes4. AOF 优点
- 数据安全性高：
everysec最多丢 1 秒数据，always几乎不丢数据。 - 可读性强：文本格式，便于人工检查和修复。
- 自动重写：避免文件无限增长。
5. AOF 缺点
- 文件体积大：记录命令比 RDB 占用更多磁盘空间。
- 恢复速度慢：需重放所有命令，尤其大文件时耗时较长。
- 对性能有一定影响：
appendfsync everysec下额外磁盘 IO，但一般可接受。
四、RDB vs AOF 对比
| 特性 | RDB | AOF |
|---|---|---|
| 存储内容 | 二进制数据快照 | 文本格式的命令日志 |
| 数据完整性 | 可能丢上次快照后的数据 | 最多丢 1 秒（everysec）或不丢（always） |
| 恢复速度 | 快（直接加载） | 慢（重放命令） |
| 文件体积 | 小（压缩） | 大（可能膨胀，可重写） |
| 对性能影响 | fork 子进程 + COW，内存大时影响明显 | 持续写入，影响较小但存在 |
| 适用场景 | 备份、灾备、快速重启 | 数据安全要求高，如金融、订单 |
五、混合持久化（Redis 4.0+）
1. 原理
混合持久化结合了 RDB 和 AOF 的优点：执行 AOF 重写时，先将当前内存数据以 RDB 二进制格式写入 AOF 文件的开头，然后继续以 AOF 格式追加后续写命令。最终生成的 AOF 文件 = RDB 头部 + 增量 AOF 命令。
恢复过程：Redis 先加载 RDB 部分快速恢复内存状态，再重放后续的 AOF 命令，保证数据完整性。
2. 开启混合持久化
# 开启混合持久化（需要同时开启 AOF） aof-use-rdb-preamble yes3. 优点
- 恢复速度快：RDB 头部大大减少重放命令数量。
- 数据安全：结合 AOF 的实时性，最多丢 1 秒数据。
- 文件体积适中：比纯 AOF 小。
4. 缺点
- 兼容性问题：旧版本 Redis 无法识别混合格式的 AOF 文件。
- 实现复杂度稍高。
企业标配：Redis 4.0+ 生产环境通常开启 AOF + 混合持久化，并配置合理的重写策略。
六、数据恢复流程
当 Redis 启动时，按以下优先级加载持久化文件：
- 如果开启 AOF，优先加载
appendonly.aof。 - 否则加载
dump.rdb。 - 如果两者都不存在，启动空实例。
加载过程中若文件损坏，可尝试使用redis-check-aof或redis-check-rdb工具修复。
七、生产环境最佳实践
1. 数据安全要求高（如交易、支付）
appendonly yes appendfsync everysec # 或 always（更安全但性能差） aof-use-rdb-preamble yes auto-aof-rewrite-min-size 64mb auto-aof-rewrite-percentage 100 # 同时开启 RDB 作为备份（可选） save 900 1 save 300 102. 对性能极致追求，容忍少量数据丢失（如缓存、计数器）
appendonly no # 只使用 RDB save 3600 1 # 每小时备份一次或者开启 AOF 但调低 fsync 频率：
appendonly yes appendfsync no3. 大数据量（> 10GB）实例
- 避免频繁 fork：调大
save间隔，减少 BGSAVE 频率。 - 控制 AOF 重写：设置
auto-aof-rewrite-min-size较大值（如 5GB）。 - 考虑关闭 RDB，仅靠 AOF，或使用主从备份代替本地持久化。
4. 监控与维护
- 监控
latest_fork_usec（最近 fork 耗时），若过高需调整内存或配置。 - 定期检查 AOF 重写是否正常执行。
- 备份 RDB 文件到远程存储（如云盘、OSS）。
八、常见面试追问
Q1：RDB 的 fork 子进程会导致 Redis 暂停服务吗？
fork 本身会短暂阻塞主进程（毫秒级），而子进程写入 RDB 文件期间对主进程无影响（COW）。但如果内存很大（几十 GB），fork 耗时可能达秒级，导致短暂请求延迟或超时。
Q2：开启 AOF 后，为什么恢复时还会丢失 1 秒数据？
appendfsync everysec下，刷盘由后台线程每秒执行一次。如果 Redis 在两次刷盘之间宕机，那部分仍在缓冲区的命令就会丢失。always可避免，但性能最差。
Q3：AOF 重写对内存有影响吗？
重写时 fork 子进程，同样存在 COW 内存翻倍的风险。如果内存使用率已很高，重写可能导致 OOM。建议预留 50% 以上空闲内存，或限制maxmemory。
Q4：主从复制场景下，持久化还需要吗？
需要。虽然从节点可以备份，但主节点不持久化，一旦主节点宕机且从节点复制延迟，可能丢失大量数据。通常主节点开启 AOF + 混合持久化，从节点可只开 RDB 用于备份。
Q5：如何从 RDB 或 AOF 中恢复误删除的数据？
无法直接恢复。只能依靠：备份文件（如之前保存的 RDB）、开启 AOF 且未重写（可手动编辑删除危险命令），或者使用第三方工具（如 redis-rdb-tools）分析。
九、总结
| 持久化方式 | 数据完整性 | 恢复速度 | 文件大小 | 性能影响 | 推荐场景 |
|---|---|---|---|---|---|
| RDB | 低（可能丢较多） | 快 | 小 | fork 时高 | 备份、快速重启 |
| AOF | 高（最多丢1秒） | 慢 | 大 | 持续低负载 | 数据安全要求高 |
| 混合模式 | 高 | 较快 | 中等 | 同 AOF | 生产首选 |
一句话记住持久化：RDB 快照恢复快，AOF 日志更完整；混合模式两全法，生产环境放心用。
选择持久化策略需要结合业务对数据丢失的容忍度、性能要求和内存规模。希望这篇文章能帮你彻底掌握 Redis 持久化，从容应对面试和实际调优，欢迎继续讨论。
