Redis 的 RDB 与 AOF：持久化机制全解析

文章目录

- [1. 引言：Redis 是内存数据库，数据会丢吗？](#1. 引言：Redis 是内存数据库，数据会丢吗？)
- [2. RDB：定期快照式持久化](#2. RDB：定期快照式持久化)
- - [2.1 什么是 RDB](#2.1 什么是 RDB)
  - [2.2 RDB 的触发方式](#2.2 RDB 的触发方式)
  - - 自动触发（配置）
    - 手动触发
  - [2.3 RDB 的工作原理](#2.3 RDB 的工作原理)
  - [2.4 RDB 的优点](#2.4 RDB 的优点)
  - [2.5 RDB 的缺点](#2.5 RDB 的缺点)
- [3. AOF：追加日志式持久化](#3. AOF：追加日志式持久化)
- - [3.1 什么是 AOF](#3.1 什么是 AOF)
  - [3.2 AOF 的开启方式](#3.2 AOF 的开启方式)
  - [3.3 AOF 写入策略（fsync）](#3.3 AOF 写入策略（fsync）)
  - [3.4 AOF 重写（Rewrite）](#3.4 AOF 重写（Rewrite）)
  - [3.5 AOF 的优点](#3.5 AOF 的优点)
  - [3.6 AOF 的缺点](#3.6 AOF 的缺点)
- [4. RDB vs AOF：核心对比](#4. RDB vs AOF：核心对比)
- [5. 同时开启 RDB + AOF](#5. 同时开启 RDB + AOF)
- [6. 生产环境配置建议](#6. 生产环境配置建议)
- - 通用建议
- [7. 一个常见误区](#7. 一个常见误区)
- [8. 总结](#8. 总结)
- 参考

1. 引言：Redis 是内存数据库，数据会丢吗？

Redis 被称为"内存数据库"，很多初学者都会有疑问：

Redis 重启后，数据还在吗？

答案是：

👉 取决于你是否开启了持久化，以及使用哪种方式。

Redis 提供了两种核心持久化机制：

RDB（Redis DataBase）快照
AOF（Append Only File）日志

它们分别从性能和数据安全两个方向解决问题。

2. RDB：定期快照式持久化

2.1 什么是 RDB

RDB 的核心思想是：

在某一时刻，把 Redis 内存中的数据完整地保存为一个快照文件。

生成的文件通常是：

latex 复制代码

dump.rdb

2.2 RDB 的触发方式

RDB 可以通过多种方式触发：

自动触发（配置）

nginx 复制代码

save 900 1
save 300 10
save 60 10000

含义：

900 秒内有 1 次写 → 生成快照
300 秒内有 10 次写
60 秒内有 10000 次写

手动触发

bash 复制代码

SAVE      # 阻塞
BGSAVE    # 后台（推荐）

2.3 RDB 的工作原理

Redis 主进程 fork 子进程
子进程将内存数据写入 .rdb 文件
主进程继续处理请求（COW 机制）

2.4 RDB 的优点

文件紧凑，体积小
恢复速度快
对 Redis 性能影响较小
适合备份、迁移

2.5 RDB 的缺点

可能丢失最近一段时间的数据
大数据量下 fork 有开销
不适合高频数据变更场景

3. AOF：追加日志式持久化

3.1 什么是 AOF

AOF 的核心思想是：

把每一次写命令，按顺序追加到日志文件中。

文件通常是：

latex 复制代码

appendonly.aof

AOF 持久化功能的实现可以简单分为 5 步：

命令追加（append）：所有的写命令会追加到 AOF 缓冲区中。
文件写入（write）：将 AOF 缓冲区的数据写入到 AOF 文件中。注意！！！此时并没有同步到磁盘。
文件同步（fsync） <font style="color:rgb(60, 60, 67);">fsync</font> 将阻塞直到写入磁盘完成后返回，保证了数据持久化。
文件重写（rewrite）：随着 AOF 文件越来越大，需要定期对 AOF 文件进行重写，达到压缩的目的。
重启加载（load）：当 Redis 重启时，可以加载 AOF 文件进行数据恢复。

3.2 AOF 的开启方式

nginx 复制代码

appendonly yes

3.3 AOF 写入策略（fsync）

nginx 复制代码

appendfsync always
appendfsync everysec
appendfsync no

策略	数据安全	性能
always	最安全	最慢
everysec	较安全	推荐
no	风险高	最快

3.4 AOF 重写（Rewrite）

随着时间推移，AOF 会越来越大，因此 Redis 提供 AOF 重写机制：

用最少的命令，重建当前数据状态。

触发方式：

自动（配置）
手动：BGREWRITEAOF

3.5 AOF 的优点

数据安全性高
丢失数据少
可读性好（文本命令）

3.6 AOF 的缺点

文件体积大
恢复速度慢
写入频繁，对磁盘依赖高

4. RDB vs AOF：核心对比

维度	RDB	AOF
持久化方式	快照	日志
数据安全	较低	较高
性能影响	小	较大
文件体积	小	大
恢复速度	快	慢
适用场景	备份	高可靠

5. 同时开启 RDB + AOF

Redis 支持两者同时开启：

nginx 复制代码

save ...
appendonly yes

启动时：

优先使用 AOF 恢复数据
RDB 作为备份手段

👉 这是生产环境的推荐方案。

6. 生产环境配置建议

通用建议

AOF 使用 everysec
开启 RDB 作为兜底
合理配置重写阈值

nginx 复制代码

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

7. 一个常见误区

AOF 一定比 RDB 安全。

实际上：

appendfsync no 风险很高
任何机制都存在极端丢失场景

8. 总结

Redis 的持久化，本质是 性能与数据安全的权衡：

RDB：快照，快、轻，但可能丢数据
AOF：日志，安全，但慢、占空间

参考

Redis持久化机制详解

文中图片来自《Redis开发与运维》