共计 1457 个字符，预计需要花费 4 分钟才能阅读完成。
Redis 提供了 两种 核心持久化机制：RDB（Redis Database） 和 AOF（Append Only File），Redis 4.0 之后还支持 混合持久化。
| 对比维度 | RDB | AOF |
|---|---|---|
| 持久化方式 | 定时对整个内存数据做快照 | 记录每一条写命令到日志 |
| 数据安全性 | 可能丢失最后一次快照后的数据 | 最多丢失 1 秒数据（everysec 策略） |
| 文件大小 | 二进制压缩，体积小 | 命令日志，体积大（重写后可缩小） |
| 恢复速度 | 快（直接加载二进制） | 慢（逐条回放命令） |
| 系统性能影响 | fork 子进程时有瞬间延迟 | 取决于 fsync 策略 |
| 适用场景 | 冷备、灾难恢复、从库同步 | 数据安全性要求高的主库 |
一句话结论：RDB 适合做 定期全量备份，恢复快但可能丢数据；AOF 适合做 实时增量备份，数据更安全但文件大、恢复慢。生产环境推荐 混合持久化（RDB + AOF）。
深度解析
一、RDB 持久化机制
RDB 是 Redis 的 默认持久化方式，它会在特定条件下将内存中的所有数据生成一个二进制快照文件（dump.rdb）。
核心要点如下：
fork()子进程：Redis 主进程调用fork()创建子进程，利用操作系统的 写时复制（Copy-On-Write，COW） 机制，子进程共享主进程的内存页。主进程继续处理客户端请求，只有在内存页被修改时才会真正复制。- 生成 RDB 文件：子进程将内存数据以二进制格式写入一个临时文件，完成后替换旧的
dump.rdb。 - 主进程无阻塞：整个过程中，主进程可以正常处理读写请求，不会阻塞（仅在
fork瞬间有短暂停顿）。
RDB 的触发方式：
- 自动触发：在
redis.conf中配置save规则：save 900 1 # 900 秒内有至少 1 次修改就触发 save 300 10 # 300 秒内有至少 10 次修改就触发 save 60 10000 # 60 秒内有至少 10000 次修改就触发 - 手动触发：执行
SAVE（阻塞主进程，不推荐）或BGSAVE（后台执行，推荐）命令。
二、AOF 持久化机制
AOF 以 追加写日志 的方式，将每一条写命令记录到 appendonly.aof 文件中。
核心流程：
- 写入缓冲区：每条写命令先追加到内存中的
aof_buf缓冲区。 - 刷盘策略：由
appendfsync配置项决定何时将缓冲区数据写入磁盘：策略 行为 数据安全 性能 always每条命令都 fsync最高，基本不丢数据 最差 everysec每秒 fsync一次最多丢 1 秒数据（推荐） 折中 no由操作系统决定刷盘 可能丢失较多数据 最好
三、AOF 重写机制
随着时间推移，AOF 文件会越来越大。Redis 提供了 AOF 重写（Rewrite） 机制来压缩文件。
AOF 重写的核心逻辑：
- 不是读取旧文件，而是直接读取当前 Redis 内存中的数据状态，用最少的命令重新生成一份 AOF 文件。
- 触发方式：
- 自动触发：
auto-aof-rewrite-percentage 100（文件大小比上次重写后增长 100%）和auto-aof-rewrite-min-size 64mb（文件最小达到 64MB）。 - 手动触发：执行
BGREWRITEAOF命令。
- 自动触发：
四、混合持久化（Redis 4.0+）
Redis 4.0 引入了 RDB + AOF 混合持久化，结合了两者的优势。
开启方式：
# 开启 AOF
appendonly yes
# 开启混合持久化
aof-use-rdb-preamble yes
混合持久化的优势：
- 恢复速度快：RDB 部分可以快速加载全量数据。
- 数据安全性高：AOF 部分记录最新变更，保证数据完整性。
- 文件体积小：RDB 二进制格式比纯 AOF 命令日志更紧凑。
正文完
