引言

Redis 是典型的内存型键值数据库，其高性能、高吞吐、低延迟的核心优势，源于 “将数据主要存储在内存中” 的设计。但纯内存存储存在一个致命缺陷：一旦发生断电、进程崩溃或机器重启，内存中的所有数据都会丢失，这在生产环境中是无法接受的。

为了兼顾 “内存的速度优势” 与 “数据的持久性需求”，Redis 提供了完善的持久化机制 —— 将内存中的数据定期写入磁盘，当 Redis 重启时，再从磁盘读取数据恢复到内存中。目前 Redis 主要支持两大类持久化方式：RDB（快照式持久化） 和 AOF（日志式持久化），在实际生产部署中，更常见两者组合使用，以平衡数据恢复速度与数据安全性。

一、RDB：快照式持久化（整体备份）

RDB（Redis Database）是 Redis 最基础的持久化方式，核心思想是 “拍摄内存数据的完整快照”，将某一时刻的全量数据集序列化后，写入磁盘的二进制文件（默认文件名：dump.rdb），重启时通过读取该文件反序列化，恢复数据状态。

1.1 底层原理

RDB 的核心是 “全量快照 + 异步执行”，为了避免持久化操作阻塞主线程（影响客户端响应），Redis 采用「fork () 子进程」的方式执行快照操作，具体逻辑如下：

  1. 触发快照后，父进程通过 fork () 创建子进程，此时父子进程共享内存页（操作系统的 Copy-On-Write 机制）；
  2. 子进程负责遍历内存中的全量数据，将其序列化、压缩后，写入临时文件；
  3. 子进程完成写入后，执行 fsync 确保数据落盘，再将临时文件原子性替换为正式的 dump.rdb（避免文件损坏）；
  4. 子进程退出，父进程全程不参与磁盘 I/O，仅在 fork 时经历短暂阻塞，不影响正常响应客户端请求。

这里的「序列化」遵循 Redis 内部的 RDB 格式，包含数据类型标识、压缩算法、校验机制等，目的是节省磁盘空间、加快序列化和反序列化速度。

1.2 快照触发方式（2 种核心方式）

RDB 快照的触发分为「自动触发」和「手动触发」，生产环境中优先使用自动触发，避免手动操作阻塞主线程。

（1）自动触发（推荐）

通过 redis.conf 配置文件中的 save 指令设置触发条件，格式为 save 秒数 写操作次数，表示 “在指定秒数内，至少发生指定次数的写操作，就触发快照”。示例配置：

conf

1
2
3
4
5
6
# 900秒内至少1次写操作，触发快照
save 900 1
# 300秒内至少10次写操作，触发快照
save 300 10
# 60秒内至少10000次写操作，触发快照
save 60 10000

多个条件满足任意一个，都会触发快照。

（2）手动触发

  • BGSAVE（推荐）：异步触发快照，fork 子进程执行，不阻塞主线程，生产环境首选；
  • SAVE（不推荐）：同步触发快照，主线程直接执行序列化和写盘操作，会阻塞所有客户端请求，仅适合小型测试环境或紧急备份。

1.3 核心问题：BGSAVE 期间，Redis 写数据会影响快照吗？

这是面试中高频问到的问题，核心答案是「不会影响」，关键在于 Copy-On-Write（写时复制）机制，具体流程如下：

  1. fork 子进程后，父子进程共享所有内存页，此时内存页的权限为「只读」；
  2. 父进程继续响应客户端写请求，当需要修改某块内存页时，操作系统会先将该内存页复制一份，给父进程分配独立的可写内存页；
  3. 子进程读取的始终是 fork 时刻的 “静态内存快照”（未被修改的原始内存页），不受父进程写操作的影响；
  4. 父进程修改的数据，不会被当前快照记录，会等待下一次快照（或 AOF 日志）持久化。

简单来说：BGSAVE 期间，写操作与快照并行执行，快照记录的是 “fork 那一刻的全量数据”，后续父进程的修改的内容，需等待下一次快照触发才能被持久化。

1.4 RDB 优点

  1. 恢复速度极快：重启时只需加载一个紧凑的二进制文件，无需逐条执行命令，尤其适合大数据量场景（GB 级数据恢复比 AOF 快数倍）；
  2. 存储文件体积小：RDB 文件经过序列化和压缩，通常比 AOF 日志文件小很多，节省磁盘空间；
  3. 对运行时性能影响小：除了 fork 子进程时的短暂阻塞，父进程无需参与磁盘 I/O，不影响客户端请求响应；
  4. 适合备份与灾备：RDB 是全量快照文件，便于离线备份、远程传输，适合用于冷备份、灾备恢复；
  5. 适配 Redis 复制机制：从节点（Slave）做部分同步时，主节点可先发 RDB 快照，再同步增量数据，效率更高。

1.5 RDB 缺点（生产环境需重点关注）

  1. 数据丢失风险高：快照是定期触发的，若 Redis 在两次快照之间崩溃，两次快照之间的所有写操作都会丢失（丢失窗口取决于快照触发频率）；
  2. fork 开销较大：对于大内存 Redis（如 10GB 以上），fork 子进程时需要复制页表，会导致主线程短暂阻塞（毫秒级到秒级），引发系统抖动；
  3. 快照过程资源消耗大：子进程遍历全量数据、序列化、写盘，会占用大量 CPU、内存带宽和磁盘 I/O，可能影响 Redis 正常性能；
  4. 快照频繁影响性能：若为了减少数据丢失，将快照触发条件配置得过于激进（如 10 秒内 1 次写操作），会导致频繁 fork 子进程，持续消耗系统资源。

二、AOF：日志式持久化（增量记录）

AOF（Append Only File）是 Redis 的另一种持久化方式，与 RDB 的 “全量快照” 不同，AOF 采用「增量日志」的思路：每执行一条会修改数据的写命令（如 SET、DEL、HSET），就将该命令以 Redis 协议格式（RESP 协议）追加到 AOF 日志文件中。

Redis 重启时，会逐行读取 AOF 日志文件中的命令，重新执行一遍，从而重建内存中的数据集。为了解决 AOF 日志无限增长的问题，Redis 引入了「AOF 重写」机制，压缩日志体积。

2.1 底层原理

AOF 的核心是 “写后日志（Write-After Log） ”，即先执行内存操作，再写入日志，这样设计的目的是避免记录无效命令（若先写日志再执行操作，操作失败会导致日志中留下无效命令）。

同时，为了平衡 “性能” 与 “数据安全性”，Redis 提供了 3 种 AOF 刷盘策略（通过 appendfsync 配置），控制日志何时从内存缓冲区写入磁盘：

  1. appendfsync always：每次写命令执行后，立即执行 fsync 刷盘（最安全，数据几乎不丢失，但性能最差，会显著增加写延迟）；
  2. appendfsync everysec（默认）：每秒执行一次 fsync 刷盘（折中方案，最多丢失 1 秒内的数据，性能与安全性兼顾）；
  3. appendfsync no：不主动执行 fsync，由操作系统决定何时刷盘（性能最好，但安全性最差，可能丢失大量数据）。

2.2 实现流程

AOF 的完整流程分为「日志写入」「日志重写」「重启恢复」三个阶段，核心是日志的追加与压缩：

（1）日志写入流程

  1. 客户端发起写命令 → Redis 先在内存中执行该命令，修改数据结构；
  2. 将该写命令以 RESP 协议格式，追加到 AOF 缓冲区（避免频繁写盘，提升性能）；
  3. 根据 appendfsync 配置的刷盘策略，将缓冲区中的命令写入 AOF 日志文件，并执行 fsync（确保数据落盘）。

（2）AOF 重写流程（核心，解决日志过大问题）

随着写命令增多，AOF 日志文件会越来越大（比如频繁执行 INCR 命令，日志会记录每一次递增操作），导致重启时重放命令耗时过长。AOF 重写的核心是 “生成当前内存数据的最小命令集”，替代原有冗余日志，流程如下：

  1. 触发重写：满足配置条件（如 auto-aof-rewrite-percentage 100，表示日志体积比上次重写后增长 100%），或手动执行 BGREWRITEAOF 命令；
  2. fork 子进程：父进程继续响应客户端请求，子进程负责重写日志；
  3. 子进程遍历内存全量数据，生成 “能恢复当前数据的最小命令集”（如多次 INCR key 合并为 SET key 最终值），写入临时 AOF 文件；
  4. 重写期间，父进程将新的写命令同时写入「旧 AOF 文件」和「重写缓冲区」（保证重写期间的写操作不丢失）；
  5. 子进程完成重写后，通知父进程，父进程将重写缓冲区中的命令追加到临时 AOF 文件；
  6. 原子性替换：将临时 AOF 文件替换为旧 AOF 文件，清理旧文件，后续写命令直接写入新 AOF 文件。

（3）重启恢复流程

  1. Redis 启动时，优先读取 AOF 文件（若同时开启 RDB 和 AOF，AOF 优先级更高，数据更完整）；
  2. 逐行读取 AOF 日志中的命令，按顺序执行，重建内存中的数据集；
  3. 若 AOF 日志文件损坏，可使用 Redis 自带的 redis-check-aof 工具修复或截断损坏部分。

2.3 核心问题：AOF 重写期间，写数据如何保证不丢失？

关键在于「重写缓冲区」的设计，具体流程如下：

  1. fork 子进程执行重写后，父进程继续处理客户端写命令；
  2. 父进程将写命令同时写入「旧 AOF 文件」（保证原有日志的连续性）和「重写缓冲区」（记录重写期间的增量操作）；
  3. 子进程完成重写后，向父进程发送信号，父进程将重写缓冲区中的所有命令，追加到新 AOF 文件的末尾；
  4. 完成追加后，原子替换旧 AOF 文件，确保新 AOF 文件包含 “重写前的全量数据 + 重写期间的增量数据”，无数据丢失。

2.4 AOF 优点

  1. 数据安全性更高：默认策略（everysec）下，最多丢失 1 秒内的数据；always 策略下，理论上可实现数据无丢失，适合对数据安全性要求高的场景；
  2. 日志可读性强：AOF 日志以文本格式（RESP 协议）记录写命令，可人工阅读、审计，甚至手动修改（慎用）；
  3. 日志追加式写入：仅追加写入，不修改已有内容，不易因意外导致日志损坏，即使损坏也可通过工具修复；
  4. 增量记录，资源消耗更均衡：无需定期做全量快照，仅记录增量命令，磁盘 I/O 压力更平稳（相比 RDB 的突发写盘）。

2.5 AOF 缺点

  1. 恢复速度慢：重启时需要逐行执行 AOF 日志中的所有命令，日志体积越大，恢复时间越长（大数据量场景比 RDB 慢很多）；
  2. 日志体积大：记录每一条写命令，尤其是频繁执行相同命令（如 INCR）时，日志会非常冗余，体积远大于 RDB 文件；
  3. 重写开销较大：重写时需要 fork 子进程、遍历全量数据、生成新日志，会占用 CPU、内存和磁盘 I/O，可能影响 Redis 性能；
  4. 刷盘策略的折中困境：always 策略性能差，no 策略安全性差，everysec 策略仍有 1 秒数据丢失风险；
  5. 命令幂等性挑战：部分命令（如 INCR、APPEND）非幂等，重放时需确保执行顺序与原始一致，否则可能导致数据不一致。

三、RDB vs AOF：深入对比与实战选择

在实际生产环境中，选择 RDB、AOF 还是两者结合，核心是权衡「数据安全性」「恢复速度」「系统性能」三个维度。以下是详细对比，帮你快速做出选择：

对比维度 RDB（快照式） AOF（日志式）
数据一致性 / 丢失风险 丢失两次快照之间的所有数据（丢失窗口较大） 最多丢失 0~1 秒数据（everysec），或无丢失（always）
重启恢复速度 快（直接加载二进制快照，无需执行命令） 慢（逐行重放日志命令，体积越大越慢）
磁盘存储空间 小（压缩后的全量快照） 大（冗余的命令日志，体积通常是 RDB 的数倍）
运行时性能影响 小（仅 fork 时短暂阻塞，无持续开销） 较大（写命令追加、fsync、重写均有持续开销）
实现复杂度 简单（快照 + 序列化） 复杂（日志追加、重写机制、恢复重放）
可读性 / 可审计 不可读（二进制文件） 可读（文本命令日志，可审计、可修复）
适合场景 1. 缓存为主，可容忍数据丢失；2. 需要快速重启；3. 冷备份、灾备 1. 业务数据为主，对数据安全性要求高；2. 写操作频繁，需减少数据丢失；3. 需要日志审计

实战推荐方案

  1. 缓存场景（如首页缓存、热点数据缓存）：仅开启 RDB，兼顾性能和快速恢复，可接受少量数据丢失；
  2. 业务数据场景（如用户信息、订单数据）：开启 AOF（everysec 策略），确保数据安全性，牺牲部分恢复速度；
  3. 高可用场景（生产核心环境）：开启 RDB + AOF 混合模式，用 RDB 加快恢复速度，用 AOF 减少数据丢失，兼顾两者优势。

四、Redis 7.0+ 混合持久化：兼顾两者的最优方案

为了解决 RDB 数据丢失多、AOF 恢复慢的问题，Redis 7.0 引入了「混合持久化（Hybrid Persistence）」机制，默认启用（通过 aof-use-rdb-preamble yes 配置），核心是 “RDB 快照 + AOF 增量日志” 的组合。

4.1 混合持久化原理

混合持久化仅在 AOF 重写时生效，重写生成的新 AOF 文件，结构分为两部分：

  1. 前缀部分：RDB 二进制快照（记录重写时刻的全量数据）；
  2. 后缀部分：AOF 增量命令日志（记录重写期间的写操作，以及重写后的所有写操作）。

文件结构示意：

plaintext

1
2
3
+----------------------+-----------------------------+
| RDB 快照二进制区块     | 增量命令日志 (AOF 部分)        |
+----------------------+-----------------------------+

4.2 恢复流程

  1. Redis 启动时，先识别 AOF 文件开头的 RDB 快照，快速加载快照（复用 RDB 的快速恢复优势）；
  2. 加载完快照后，继续读取后缀的 AOF 增量日志，逐行执行命令，恢复重写期间及之后的增量数据；
  3. 最终恢复到 Redis 崩溃前的完整数据状态。

4.3 混合持久化优缺点

优点

  1. 恢复速度快：大部分数据通过 RDB 快照加载，仅少量增量命令需要重放，解决了纯 AOF 恢复慢的问题；
  2. 数据安全性高：保留 AOF 增量日志，最多丢失 1 秒数据，解决了纯 RDB 数据丢失多的问题；
  3. 日志体积可控：RDB 快照压缩存储，AOF 仅记录增量命令，日志体积比纯 AOF 小很多；
  4. 兼顾性能与可靠性：重写时生成 RDB 快照，比纯 AOF 重写更高效，同时保留增量日志的安全性。

缺点

  1. 实现复杂度高：结合了 RDB 和 AOF 的机制，对 Redis 底层代码和配置管理要求更高；
  2. 版本限制：仅 Redis 7.0 及以上版本支持，老版本无法使用；
  3. 文件管理要求高：混合 AOF 文件包含二进制和文本两部分，损坏后修复难度比纯 AOF 略高。

实战建议

如果你的 Redis 版本是 7.0 及以上，优先启用混合持久化，这是目前 Redis 持久化的最优方案，既能享受 RDB 的快速恢复优势，又能获得 AOF 的高数据安全性。

全文总结

Redis 持久化的核心目标是 “在内存速度与数据持久性之间找到平衡”，RDB 和 AOF 各有优劣，混合持久化则是两者的最优折中，总结如下：

  1. RDB：全量快照，恢复快、体积小，但数据丢失风险高，适合缓存、备份场景；
  2. AOF：增量日志，数据安全性高、可读性强，但恢复慢、体积大，适合业务数据场景；
  3. 混合持久化（Redis 7.0+）：RDB 前缀 + AOF 后缀，兼顾恢复速度和数据安全性，生产核心环境首选。

面试小贴士

被问到 Redis 持久化时，不要只罗列 RDB 和 AOF 的优缺点，要结合场景分析：

  1. 先讲持久化的必要性（内存数据库断电丢数据）；
  2. 分别讲 RDB 和 AOF 的原理、核心问题（如 COW 机制、重写缓冲区）；
  3. 对比两者的差异，给出实战选择建议；
  4. 补充 Redis 7.0 混合持久化的优势，体现知识点的完整性。