Redis 的持久化机制是什么？各自的优缺点？

Sun, 28 Jun 2026 22:59:57 +0800

先说结论：三种持久化机制的优缺点，主要根因都指向同一个底层机制：fork() + COW。理解它，就能解释 RDB 的数据丢失窗口、AOF 的重写阻塞、混合持久化的折中逻辑，也能解释为什么生产环境会炸（OOM），以及为什么你对"AOF 不丢数据"的理解是错的。

注意我说的是"主要根因"，不是"唯一根因"。AOF 还多出一个 fsync 策略维度，这是 fork+COW 解释不了的。这个区分很重要，后面会展开。

下面会用 Docker 跑一组实测，把官方文档里的文字结论变成你能复现的数据。

TL;DR：

三件套（RDB/AOF/混合）的优缺点主要根因都是 fork()+COW，AOF 多一个 fsync 独立维度
混合持久化不是新机制，是 AOF 重写的默认行为（5.0+ 默认启用 aof-use-rdb-preamble）
写入密集场景 BGSAVE 期间 RSS 可暴涨到基准 6.41 倍，主因是父进程持续写入分配新内存，不是 COW 复制
“AOF 不丢数据"是错的，everysec 最多丢 1 秒；“混合持久化是折中"也是错的，它是默认行为
选型三维度：写入模式 × 内存约束 × 数据安全要求

一、三件套是什么

Redis 持久化有三件套：RDB、AOF、混合持久化。一句话讲清每种的本质。

RDB（Redis Database）：定时对内存数据拍快照，存成紧凑的二进制文件。类比拍照，按下快门那一刻定格。

AOF（Append Only File）：把每条写命令追加到日志，重启时重放恢复。类比录像，一直录，按策略刷盘。

混合持久化就是 AOF 重写时用 RDB 格式做 base file，后续追加 AOF 增量，相当于带定妆照的录像。

这里有个容易忽略的细节：Redis 4.0 引入 aof-use-rdb-preamble 选项，开启后 AOF 重写产出的 base file 就是 RDB 格式。Redis 5.0+ 这个选项默认启用。也就是说，所谓"混合持久化"不是新机制，而是 AOF 重写的默认行为。Redis 7.0 在此基础上引入了 multi-part AOF 结构，把单文件拆成 base + incr + manifest，但"aof-use-rdb-preamble 默认 yes"这件事从 5.0 就成立了。

Redis 7.0 的 multi-part AOF

还有个变化值得提。Redis 7.0 之前，AOF 是单个 appendonly.aof 文件。7.0 改成了 multi-part 结构：

appendonlydir/
├── appendonly.aof.1.base.rdb   # base file（RDB 格式，aof-use-rdb-preamble 启用时）
├── appendonly.aof.1.incr.aof   # 增量日志（AOF 命令格式）
└── appendonly.aof.manifest     # 清单文件（记录当前文件结构）

base file 是重写那一刻的内存快照，incr.aof 是重写之后的新写入。manifest 文件记录当前由哪些文件组成。这个结构的好处是：重写过程中如果崩溃，旧文件还在，不会出现"重写到一半文件损坏"的问题。

为什么要提这个？因为很多人对 AOF 的印象还停留在"单个大文件"时代。7.0+ 的 AOF 已经不是那个样子了。

我跑了一组实测验证这点：100 万 key，同样的数据，RDB 文件 24,777,889 字节，AOF 重写后的 base.rdb 也是 24,777,889 字节，本实验条件下字节级一致。AOF 总大小 = base.rdb + incr.aof（增量日志）+ manifest（清单文件）。重写后立即看，incr.aof 是 0 字节，AOF 总大小只比 RDB 多 88 字节（manifest 开销）。

理解了"混合持久化 = AOF 重写用 RDB 做 base”，后面优缺点的逻辑就顺了。

二、各自的优缺点（标准视角）

先把官方文档的优缺点表摆出来，再用实测数据对照。

RDB 的优缺点

优点：

文件紧凑，适合备份和灾难恢复
恢复速度快（二进制格式直接加载）
fork 子进程后台执行，不影响主线程性能

缺点：

两次快照之间的写入会丢失（数据丢失窗口 = save 间隔）
大数据集 fork 耗时，可能阻塞主线程

AOF 的优缺点

优点：

数据安全性高（最多丢 1 秒，取决于 fsync 策略）
日志格式可读，可修复损坏文件
重写后 base file 用 RDB 格式（5.0+ 默认），恢复速度接近 RDB

缺点：

文件大（增量日志累积后）
恢复慢（增量部分需重放命令）
写入有性能开销（fsync 策略影响吞吐）

AOF 的数据安全性由 fsync 策略决定，这是 AOF 独立于 fork+COW 的维度：

fsync 策略	含义	丢失窗口	性能影响
always	每条命令 fsync	理论零丢失	吞吐量大幅下降
everysec	每秒 fsync 一次	最多 1 秒	性能损失很小
no	由 OS 决定	可能数十秒	性能最好

大多数人选 everysec，是性能和安全性的平衡。但要注意：everysec 承诺的是"最多丢 1 秒”，不是"零丢失"。这个区别在第五节会展开。

混合持久化的优缺点

优点：

兼具 RDB 的恢复速度和 AOF 的数据安全性
Redis 7.0+ 默认启用，无需额外配置

缺点：

依然要 fork（AOF 重写触发）
增量部分仍是 AOF 格式，长期运行后文件会增长

实测与推演对照

Docker 跑了 100 万 key 的对照实验，验证几个关键优缺点：

指标	RDB	AOF（重写后）	说明
文件大小	24,777,889 字节	24,777,977 字节	AOF 多 88 字节（manifest），base.rdb 完全一致
恢复速度	快	推演：base 部分同 RDB，增量部分需重放	aof-use-rdb-preamble 让 base 用 RDB 格式

从文件大小看，aof-use-rdb-preamble 启用后，AOF 的 base file 与 RDB 文件大小完全一致。网上常见说法是"AOF 文件比 RDB 大很多"，这只在增量日志累积后才成立。刚重写完的 AOF，base 部分就是 RDB。

恢复速度这部分没能实测到。我试图用 Redis 的 loading_total_time 指标测恢复时间，但 Redis 7.4 加载速度极快，100 万 key 在毫秒级完成，轮询未能捕捉到加载过程。Redis 没有暴露加载过程的细粒度时间指标，loading_total_time 是完成后才填入的累计值，无法在加载过程中采样。基于文件结构分析：aof-use-rdb-preamble 启用后，AOF base 部分加载速度与 RDB 相同；差异来自 incr.aof 增量命令重放。生产环境 AOF 持续运行时 incr.aof 会累积，恢复时间通常长于纯 RDB（刚重写完 incr.aof 为空时，恢复时间与纯 RDB 几乎相同）。这是推演，不是实测，但逻辑成立。

三、底层根因：fork() + COW

为什么 RDB 和 AOF 的优缺点有那么多相似之处？因为它们都靠同一个机制实现后台持久化：fork() + COW。

Redis 做 BGSAVE 或 AOF 重写时，主进程 fork 出一个子进程，父子进程共享内存页，子进程负责把内存数据写到磁盘文件。写入时通过 COW（Copy-on-Write，写时复制）复制被写入的页，这样子进程能安全访问 fork 那一刻的内存快照，父进程继续处理客户端请求。

机制本身很优雅：持久化不阻塞主线程，子进程拿快照写文件，父进程照常工作。问题出在"父进程继续写入"这一点上。

fork() 的两个代价

fork() 不是免费的，它有两个代价：

代价一：内存翻倍风险。fork 那一刻，子进程和父进程共享所有内存页。之后父进程继续写入，写入的页通过 COW 复制。如果 fork 期间写入量大，RSS 会显著增长，具体增长多少取决于写入模式，第四节会用实测数据说明。

代价二：主线程阻塞。fork() 系统调用本身是同步的，在父进程执行期间，主线程被阻塞。Redis 单线程模型下，这意味着所有客户端请求都要等 fork 完成。fork 阻塞期间客户端请求会被排队等待，阻塞过久可能触发客户端超时重连。fork 耗时与数据集大小正相关，数据集越大，fork 越慢，阻塞越久。

实测了不同数据集的 fork 耗时：

数据集	latest_fork_usec	fork 耗时
1 万 key	243μs	0.24ms
10 万 key	168μs	0.16ms
100 万 key	403μs	0.40ms

10 万 key 比 1 万 key 还快，这有点反直觉。这是单次测量的波动，n=1 不能作为定量依据。100 万 key 时 fork 耗时 0.40ms，比 1 万 key 高一个量级，但 1 万→10 万的方向反转说明容器调度噪声不可忽略。生产环境 10GB+ 的 Redis 实例，fork 耗时可能达到百毫秒级（这是社区共识的方向性判断，本文未做大实例实测），这就是为什么大实例会出延迟尖峰。

RDB 和 AOF 怎么用 fork+COW

RDB 触发 BGSAVE → fork() → 子进程遍历内存写 dump.rdb。fork 频繁程度取决于 save 规则（如 save 900 1 = 900 秒内至少 1 个变更就触发）。

AOF 重写 触发 BGREWRITEAOF → fork() → 子进程把当前内存转成新 AOF（aof-use-rdb-preamble 启用时用 RDB 格式做 base）→ 重写完成后替换旧 AOF。AOF fork 较少，只在重写时触发。

混合持久化就是 AOF 重写用 RDB 做 base，机制上和 AOF 重写是同一回事。

三者都绕不开 fork+COW。这就是为什么它们的优缺点有对称性：

RDB fork 频繁（按 save 规则）/ AOF fork 较少（仅重写时），但都要 fork
RDB 数据丢失窗口 = save 间隔 / AOF 数据丢失窗口 = fsync 间隔，不同的丢失机制
RDB 文件小 = 二进制紧凑 / AOF 文件大 = 增量日志冗余，但 base 部分都是 RDB

一个重要的修正：fsync 是 AOF 独立的维度

三件套优缺点不能完全归因到 fork+COW。AOF 的"慢"来自两个独立机制：

fsync 策略（always / everysec / no），磁盘 I/O 操作，与 fork+COW 无关（策略详情见第二节 fsync 表）
fork + COW（AOF 重写时），内存操作

RDB 只有 fork+COW 一个维度。AOF 是双根因：fsync 策略（日常写入）+ fork+COW（重写时）。混合持久化的增量部分仍是 AOF，所以也是双根因。

fsync 策略是 AOF 独有的维度，不能用 fork+COW 解释。 这个区分让论点更精确，避免把所有问题都归因到 fork+COW 上。

四、为什么会炸：fork/COW 触发 OOM 的真实事故链

机制本身没问题，问题出在写入密集场景。数据比我预期的更激烈。

实测：写入密集 + fork 期间 RSS 暴涨 6.41 倍

实验设计：Docker 起 Redis 7.4，先灌入 50 万 key（基础内存约 39.4MB），然后启动 200 万 key 的写入负载，同时触发 BGSAVE，每秒采样 INFO memory 的 used_memory_rss。

结果：

采样点	used_memory_rss	相对基准 used_memory
BGSAVE 前	49MB	100%
+1s	120MB	292%
+2s	230MB	557%
+3s	252MB（峰值）	641%
+4s~+10s	252MB	641%

RSS 从 49MB 涨到 252MB，是基准 used_memory 的 6.41 倍。如果这个 Redis 跑在内存上限 240MB 的容器里，BGSAVE 期间直接 OOM。

实验设计说明：这组实验同时启动了写入负载和 BGSAVE，没有单独跑"仅写入不 BGSAVE"的对照组，因此 6.41 倍中 fork COW 与写入负载各自的占比无法精确拆分。F3 空闲场景对照（无写入时 BGSAVE，RSS 仅增长 0.28%）只能证明"无写入时 RSS 几乎不涨"，不能反向推出"写入负载是主因"。下一节的"诚实修正"基于 COW 复制量数据（1.1%）做的归因，是一个方向性判断，不是精确的定量拆分。

诚实修正：RSS 暴涨的主因不是 COW 复制

这里要做一个重要的诚实修正。

我最初以为 RSS 暴涨是 COW 复制导致的——fork 后父进程写入，每��被写入的页都复制一份，RSS 翻倍。但实测数据不支持这个判断：

rdb_last_cow_size（COW 复制量）：462,848 字节（约 0.44MB）
占 used_memory 比例：1.1%

COW 只复制了 0.44MB，但 RSS 涨了 200MB+。这说明 RSS 暴涨的主因不是 COW 复制，而是写入密集负载本身在持续分配新内存（200 万新 key 写入，每个 key-value 占用内存，父进程 RSS 持续增长）。fork 期间父进程继续接收写入，子进程持有旧页快照，父进程新写入分配新页，两部分都计入 RSS。而 COW 只在写入已存在页时触发，新 key 是分配新页不触发 COW，只有修改已有 key 才触发 COW。

这里要做一个场景限定声明：本实验用 redis-benchmark 写新 key，COW 占比低是预期行为（新 key 分配新页，不触发 COW）。若实验改为修改已有 key，COW 占比会上升。本实验的"修正"结论限定于"写入密集负载以新 key 为主"的场景，不适用于"频繁修改已有 key"的场景。

对照实验（F3 证伪）：空闲无写入场景下 BGSAVE，RSS 仅增长 0.28%，COW 复制量也是 1.1%。这验证了"翻倍是写入密集场景特定现象"。

生产环境 OOM 的真正机制

基于实测修正后的理解，fork 期间 OOM 的真正机制是：

fork() 触发，子进程持有当前内存快照
父进程继续接收写入，新写入分配新内存页（这是 RSS 增长主因）
父进程修改已有 key，触发 COW 复制（次因，实测仅 1.1%）
RSS = 子进程快照 + 父进程新写入 + COW 复制 > 物理内存上限
cgroup OOM killer 触发，Redis 进程被杀

关键监控指标有三个：rdb_last_cow_size / aof_last_cow_size（COW 复制量，次因）、used_memory_rss 在 BGSAVE/AOF_REWRITE 期间的增长（主因）、used_memory 与 maxmemory 的距离（缓冲空间）。

另一个独立的内存风险：AOF 重写缓冲区

除了 fork+COW，AOF 重写期间还有一个独立的内存风险源。重写期间父进程新写入的命令会同时写到旧 AOF 和 aof_rewrite_buffer 中（用于重写完成后追加到新 AOF 末尾）。如果重写耗时长且写入量大，这个 buffer 会持续增长。这是 fork+COW 之外的正交维度——即使 COW 复制量很小，重写缓冲区仍可能占用大量内存。监控时除了 aof_last_cow_size，也要关注重写期间的 used_memory 增长趋势。

THP 放大效应

还有个放大器叫 THP（Transparent Huge Pages）。Linux 默认内存页 4KB，THP 把 4KB 小页合并成 2MB 大页。COW 时，即使只写一个字节，也要复制整个 2MB 页——单次 COW 复制的页大小放大 512 倍（2MB/4KB），实际 RSS 放大取决于被 COW 的大页数量。

我试图在 Docker 里实测 THP 开/关的 COW 差异，但结果与理论预期相反（可能是 macOS Docker Desktop 的 LinuxKit 内核行为与原生 Linux 不一致）。以下 THP 部分的实测环境为 macOS Docker Desktop，与生产 Linux 环境可能有差异，实测数据未采用，仅作理论推演 + 官方说明佐证。

逻辑上的放大机制是成立的：2MB 大页的 COW 复制量远大于 4KB 小页。Redis 官方在 redis.conf 中明确说明了这个风险：

“On systems in which it (THP) is set to ‘always’, redis will attempt to disable it specifically for the redis process in order to avoid latency problems specifically with fork(2) and CoW.” —— Redis 7.4 redis.conf，disable-thp 配置项说明

Redis 7.0+ 甚至新增了 disable-thp yes 配置项，让 Redis 进程启动时主动关闭自己的 THP，规避 fork+COW 的延迟问题。这是官方对"THP + fork + COW 有问题"的明确承认。

生产建议：Redis 机器关掉 THP（参考 Redis 官方 redis.conf 说明与 disable-thp 配置，本实验未能直接验证）。echo never > /sys/kernel/mm/transparent_hugepage/enabled，或在 Redis 7.0+ 配置 disable-thp yes 让 Redis 自己处理。

五、4 个认知偏差

讲完机制，纠正几个常见的认知偏差，按纠正价值从高到低排列。

偏差	常见误解	准确说法	实测证据
一	AOF 不丢数据	everysec 最多丢 1 秒	kill -9 实验：5 万写入丢失 1,230（2.46%）
二	RDB 备份够用	save 间隔内数据会丢	save 900 1 最坏丢 15 分钟
三	混合是折中	5.0+ 默认行为	aof-use-rdb-preamble 5.0 默认 yes
四	持久化无代价	fork+COW 有 OOM 风险	BGSAVE 期间 RSS 6.41 倍

偏差一：AOF 不丢数据

“AOF 不丢数据"是错的。这个误解在官方文档层面其实已有说明（everysec 的措辞是 “very safe” 不是 “zero loss”），但工程实践中仍有团队误以为 everysec = 不丢数据。准确说法取决于 fsync 策略：

AOF + always：每条命令 fsync，理论零丢失，但性能大幅下降
AOF + everysec：每秒 fsync 一次，最多丢 1 秒
AOF + no：由 OS 决定 fsync，可能丢数十秒

Redis 官方文档对 everysec 的措辞是 “very safe”（非常安全），不是 “zero loss”（零丢失）。

这个误解的来源：很多人把"AOF 比较安全"等同于"AOF 不丢数据”。官方文档说 everysec 是 “very safe”，但 “very safe” 和 “zero loss” 是两回事。销售文案和工程承诺之间有差距——工程承诺要精确到丢失窗口。

我跑了一个断电模拟实验：AOF everysec 策略，灌入 10 万基础 key，启动 redis-benchmark 持续写入 5 万 key，0.5 秒后 kill -9 模拟断电。重启后检查：实际写入 48,770 key，丢失 1,230 key（2.46%）。

需要说明的是，kill -9 模拟的是进程被杀，不是真实断电。真实断电时 OS page cache 全部丢失，AOF 缓冲区未刷盘部分必然丢失，实际丢失可能更多。另外，kill -9 后 AOF 文件可能不完整（半条命令），Redis 重启时会 truncate 到最后一条完整命令，这个修复过程也可能额外丢失数据。所以 kill -9 与真实断电的丢失量方向不确定，但这次实验已经足以证明：AOF everysec 存在丢失窗口，“不丢数据"是错的认知。

所以 AOF everysec 承诺"最多丢 1 秒”，这是明确的上界。如果你的业务不能容忍任何丢失，要么用 always（性能代价），要么别用 Redis 做主存储。

偏差二：RDB 备份够用

“用 RDB 做定时备份就够了”——取决于你的业务能否容忍 save 间隔内的数据丢失。

RDB 的数据丢失窗口 = save 规则间隔。save 规则是"变更次数 + 时间窗口"复合触发，如 save 900 1 表示 900 秒内至少 1 个变更才触发，最坏情况是刚 save 完后 900 秒内的变更全部丢失。如果配置 save 900 1（900 秒内至少 1 个变更就触发），最坏情况丢失 15 分钟数据。对于缓存场景可能没问题，对于订单、支付这类业务就是事故。

这个误解的来源：很多人把"RDB 是快照备份"等同于"RDB 是完整备份"。快照是某个时间点的状态，不是连续记录。两次快照之间的变更，快照里没有。

判断标准：业务能容忍"回到 15 分钟前"就用 RDB，不能就上 AOF。这是业务判断，不是技术判断——技术方案的选择应该由业务对数据丢失的容忍度驱动，而不是由"哪个更简单"驱动。

偏差三：混合持久化是折中

“混合持久化是 RDB 和 AOF 的折中”——这个说法暗示它是第三种独立机制。其实不是。

如第一节所述，aof-use-rdb-preamble 5.0+ 默认启用，7.0 又引入 multi-part AOF 结构，所谓"混合持久化"就是 AOF 重写默认行为。它不是"折中"，而是"默认"。“要不要开启混合持久化"在 5.0+ 就是个伪问题。

这个误解的来源：Redis 4.0 刚引入 aof-use-rdb-preamble 时默认是 no，那时确实需要手动开启。5.0 改为默认 yes 后成了标准行为。很多教程还停留在 4.0 时代的表述。

偏差四：持久化无代价

“开持久化总是好的”——持久化有代价。

代价就是 fork+COW。第四节的实测数据：写入密集场景下 BGSAVE 期间 RSS 暴涨到基准的 6.41 倍。如果你的 Redis 跑在内存吃紧的环境，开持久化 = 增加 OOM 风险。

另一个代价是 fork 阻塞。实测 fork 耗时随数据集增长：

数据集	latest_fork_usec	fork 耗时
1 万 key	243μs	0.24ms
10 万 key	168μs	0.16ms
100 万 key	403μs	0.40ms

Redis 单线程模型下，fork 期间主线程阻塞。大数据集 fork 耗时可能进入毫秒甚至百毫秒级（方向性判断，本文 100 万 key 实测仅 0.40ms，更大实例未做实测），会导致延迟尖峰。

六、怎么选：三维决策框架

讲了这么多机制，落到"怎么选”。用三个维度判断（本框架是通用工程经验整理，非从本文实测数据提炼）：

维度一：写入模式

写入密集（高频写、大 key）→ fork 风险高，监控 rdb_last_cow_size 和 RSS 增长
读多写少 → fork 风险低，RDB 足够

维度二：内存约束

内存充裕（used_memory < 物理内存的 50%）→ fork 期间 RSS 翻倍也有缓冲（读多写少场景适用）
内存吃紧（used_memory > 物理内存的 70%）→ fork 期间 OOM 风险高，考虑关闭持久化或扩容
写入密集场景需更保守，建议 used_memory < 物理内存 15-20%，或根据实测 RSS 峰值倒推（第四节实测 RSS 可达基准 6.41 倍）

维度三：数据安全要求

能容忍分钟级丢失 → RDB
只能容忍秒级丢失 → AOF everysec
不能丢失任何数据 → 别用 Redis 做主存储，用真正的数据库

配置建议：

大多数场景：AOF everysec + aof-use-rdb-preamble（5.0+ 默认）+ 关闭 THP
纯缓存场景：RDB only 或关闭持久化
内存敏感场景：监控 rdb_last_cow_size / aof_last_cow_size / latest_fork_usec，设告警阈值

七、结语

回到开头那个结论：三种持久化机制的优缺点，主要根因都指向 fork() + COW。RDB 完全靠它，AOF 重写靠它，混合持久化的 base file 生成也靠它。AOF 多了一个 fsync 策略维度，这是 fork+COW 解释不了的。

如果你只能记住一件事，记住这个：fork() 不是免费的，它会让你的 RSS 在写入密集场景暴涨——但主因是父进程持续写入分配新内存，不是 COW 复制本身。下次你看 Redis INFO 输出，先看 rdb_last_cow_size 和 used_memory_rss 在 BGSAVE 期间的变化，再看 latest_fork_usec。这些数字告诉你持久化的真实代价。

以上基于 Docker 实测和官方文档梳理，生产环境的具体阈值还需按业务场景验证，欢迎讨论。

附录：实验代码和原始数据

本文 6 组实验 + 4 组证伪实验的代码和原始输出已开源：

GitHub：zhiyulab-evidence/redis-persistence

子目录说明：

code/e1-file-size/ — 100 万 key RDB vs AOF 文件大小对比
code/e2-recovery-time/ — 恢复时间实验（Redis 7.4 加载太快采集失败，正文用推演）
code/e3-rss-spike/ — 写入密集场景 fork 期间 RSS 暴涨实测
code/e4-thp/ — THP 放大效应（macOS Docker Desktop 环境结果与理论相反，正文降级为推演 + 官方说明）
code/e5-power-loss/ — AOF everysec 断电丢失窗口模拟
code/e6-fork-duration/ — fork 耗时随数据集变化
code/falsification/ — 4 组证伪实验（F1 文件大小 / F2 恢复时间 / F3 RSS 翻倍 / F4 单一根因）
output/ — 各实验的原始输出（INFO memory 采样、redis-cli 输出、文件大小记录）

每个子目录都有独立 README 说明如何复现。Docker 环境 macOS Docker Desktop 与生产 Linux 可能有差异，已在正文相应段落标注。

原文发布于止语Lab

Fork on 止语Lab