问题: Redis 的 RDB 和 AOF 持久化机制各自的工作原理是什么？对比它们的优缺点及适用场景；Redis 4.0 引入的混合持久化是如何兼顾恢复速度与数据安全性的？

👇 点击展开/折叠 面试背诵模板（建议先背这个） RDB 通过 fork 子进程定期生成内存快照的二进制文件，恢复极快、文件紧凑，适合备份，但两次快照间的数据可能丢失。AOF 以追加方式记录每个写命令，通过 fsync 策略控制落盘，最多丢 1 秒数据（everysec），安全性高，但文件大、恢复慢。Redis 4.0 引入混合持久化，重写 AOF 时将当前全量数据以 RDB 二进制格式写入文件头部，后续增量命令以 AOF 格式追加。恢复时先快速加载 RDB 部分，再重放少量 AOF 命令，兼顾恢复速度与数据安全。
---

RDB (Redis Database) 持久化

工作原理：RDB 在指定时间间隔生成数据集的时间点快照，保存为紧凑的二进制文件。生成方式有手动（SAVE 阻塞主线程 / BGSAVE 后台子进程）和自动（配置文件 save <seconds> <changes> 触发 BGSAVE）。

优点：

  • 恢复速度快：直接加载二进制文件，适合大数据量快速恢复
  • 性能开销小：主进程仅 fork 子进程，不执行磁盘 I/O
  • 文件紧凑：单一二进制文件，便于备份和跨数据中心传输

缺点：

  • 可能丢失数据：两次快照间隔内的写操作在宕机时无法恢复
  • fork 开销：数据集很大时，fork 子进程可能阻塞服务数毫秒甚至一秒

适用场景：对数据实时性要求不高、需快速恢复大数据量的灾难备份场景。

AOF (Append Only File) 持久化

工作原理：记录服务器接收到的每个写操作命令，以追加方式写入日志文件。通过 appendfsync 配置控制落盘策略：

  • always：每个命令同步落盘，最安全，性能最差
  • everysec：每秒同步一次，最多丢 1 秒数据，生产环境推荐
  • no：由操作系统决定，性能最好，安全性最低

优点：

  • 数据安全性高：everysec 策略最多丢失 1 秒数据
  • 日志可读：文本格式记录所有写操作，便于故障分析
  • 自动重写：文件过大时，后台重写压缩为最小操作集

缺点：

  • 文件体积大：记录所有写操作，通常比 RDB 大
  • 恢复速度慢：需重放所有命令
  • 性能开销：always 策略下频繁 fsync 影响性能

适用场景：需要高数据安全性、能接受较大存储空间和稍慢恢复速度的场景。

混合持久化 (Hybrid Persistence)

引入背景：RDB 可能丢数据，AOF 恢复慢。Redis 4.0 引入混合持久化，结合两者优点。

工作原理：开启 aof-use-rdb-preamble yes 后，AOF 重写时，子进程先将当前全量数据以 RDB 二进制格式写入文件头部，后续增量命令再以 AOF 文本格式追加。最终文件结构为：[RDB Header][RDB Data][AOF Commands]。

恢复流程：加载时先快速加载 RDB 部分恢复全量数据，再重放少量 AOF 命令补全增量。既保证了恢复速度，又降低了数据丢失风险。

优势：相比纯 AOF，文件体积减少 30%-50%；相比纯 RDB，数据安全性更高。