20. 持久化混合与选型

前面两章分别看了 RDB（快照快、恢复快，但丢两次快照间的数据）和 AOF（几乎不丢、但文件大、恢复慢）。一个自然的问题是：能不能既要 RDB 的速度，又要 AOF 的安全？ 答案正是“同时开启”，并且在 Redis 7 之后进一步演化为更优雅的混合形态。

本章我们把两种方案放在一起，讲清楚它们如何共存、启动时谁优先，以及生产环境该怎么选。

本节目标

• 理解 RDB 与 AOF 可以同时开启，且启动时以 AOF 为准。
• 了解 Redis 7+ 的 AOF 结构：base 基础文件可兼用 RDB 格式（混合持久化）。
• 掌握 aof-use-rdb-preamble 等混合相关配置。
• 根据“数据重要性 / 恢复速度 / 运维成本”三维度做选型。
• 形成一份可直接落地的生产持久化配置建议。

两者同时开启会怎样

在 redis.conf 里完全可以这样写：

save 3600 1 300 100 60 10000
appendonly yes

此时 Redis 一边按 save 条件做 RDB 快照，一边把写命令追加进 AOF。启动时，Redis 会优先加载 AOF——因为 AOF 通常包含更近的数据，完整性更高；只有 AOF 关闭时，才会去加载 dump.rdb。这就是为什么即便你同时保留了两种文件，恢复出来的数据也以 AOF 为准。

换句话说：两者不是“二选一互相替代”，而是 AOF 负责“日常近实时恢复”，RDB 负责“做紧凑备份、快速迁移、以及给 AOF 一个兜底快照”。

混合持久化：RDB 前缀 + AOF 增量

从 Redis 7 起，AOF 不再是一个纯文本命令文件，而是一组文件：一个 base 基础文件加上若干 incr 增量文件，再由 manifest 清单记录顺序。关键在于——这个 base 文件本身可以是 RDB 格式。

具体机制是：当 AOF 重写发生时，Redis 先把当前内存全量数据以 RDB 格式写进 base 文件（这就是“RDB 前缀”，速度极快、文件紧凑），随后把重写期间产生的新写命令以普通 AOF 格式追加为 incr 增量文件。恢复时，先按 RDB 快速载入全量，再重放少量增量命令补齐到最新状态。

这样既保留了 RDB“恢复快、体积小”的优点，又通过增量 AOF 把数据丢失控制在秒级，是两全其美的方案。该行为由 aof-use-rdb-preamble 控制（Redis 7+ 默认开启）：

127.0.0.1:6379> CONFIG GET aof-use-rdb-preamble
1) "aof-use-rdb-preamble"
2) "yes"

观察 AOF 目录结构（Redis 8 默认）：

127.0.0.1:6379> CONFIG GET appenddirname
1) "appenddirname"
2) "appendonlydir"

# 磁盘上大致长这样
# appendonlydir/
#   appendonly.aof.1.base.rdb   <- 基础快照（RDB 格式）
#   appendonly.aof.1.incr.aof   <- 增量命令
#   appendonly.aof.manifest     <- 清单

落盘策略与 fsync 再回顾

AOF 的可靠性由 appendfsync 决定：生产推荐 everysec（默认，最多丢约 1 秒）；对丢失零容忍的金融类场景可用 always（性能代价高）；纯缓存、能接受丢数据则可用 no。混合持久化下这个策略依然作用于 incr 增量文件的刷盘。

与之配合，no-appendfsync-on-rewrite 控制“重写期间是否暂停 fsync”。默认 no（重写时也 fsync，最安全）；若重写导致明显延迟毛刺且你能接受最坏约 30 秒日志丢失，可设为 yes。

生产环境选型建议

并没有“万能配置”，按下面三个维度对号入座：

场景一：纯缓存（如会话缓存、热点数据） 可以只开 RDB，甚至把 save 调稀疏（如 save 900 1）。丢了能从后端数据库重建，恢复快最重要。若担心瞬时雪崩，可加 allkeys-lru 淘汰策略配合。

场景二：需要近实时持久化（如排行榜、计数器、消息元数据） 开启 AOF，appendfsync everysec，并保留 RDB 作为定时备份。这是最常用、最平衡的组合。

场景三：几乎不能丢数据（如把 Redis 当主存储） AOF + appendfsync always，并配合主从复制与定期 RDB 备份。注意 always 对磁盘吞吐要求高，建议使用低延迟 SSD。

场景四：极致恢复速度 + 可控丢失 直接采用默认的混合持久化（aof-use-rdb-preamble yes），既快又稳。

无论哪种场景，都建议：

• 用 dir 把持久化文件放到独立、可靠的磁盘分区，避免和系统盘抢 I/O。
• 定期把 RDB / AOF 目录拷贝到异地或对象存储做真正的备份（Redis 自身的持久化不等于备份）。
• 监控 INFO persistence 中的 rdb_last_bgsave_status、aof_last_bgrewrite_status，一旦变 err 及时告警。
• 内存很大时留意 BGSAVE / 重写的 fork 毛刺，必要时调大机器内存余量。

小结

• RDB 与 AOF 可同时开启；启动时 AOF 优先，RDB 作为备份与兜底。
• Redis 7+ 的混合持久化：AOF 的 base 文件用 RDB 格式，增量用 AOF 命令，默认开启。
• appendfsync everysec 是通用推荐；零丢失用 always，纯缓存可用 no。
• 选型看三维度：数据重要性、恢复速度、运维成本；混合持久化是多数生产环境的平衡点。
• 持久化 ≠ 备份，重要数据务必定期把文件拷到异地。

常见误区

• 误区一：同时开 RDB 和 AOF 会“双倍写入、性能减半”。 两者机制独立：RDB 只在满足 save 条件时做快照，AOF 按写追加并 fsync，彼此开销互不放大，生产环境同开是很常见且推荐的做法。
• 误区二：AOF 优先加载，RDB 就没用了。 恰恰相反，RDB 仍是做定时冷备份、跨机房迁移、以及给 AOF 提供“全量兜底快照”的关键手段。没有 RDB，单纯靠 AOF 做整库迁移会更笨重。
• 误区三：混合持久化下 AOF 还是单个文本文件。 Redis 7+ 的 AOF 是一个目录（appendonlydir/），内含 base 基础文件（RDB 或 AOF 格式）、多个 incr 增量文件和 manifest 清单。备份时要连同整个目录一起拷，只拿一个文件会丢增量。
• 误区四：开了持久化就等于做了备份。 持久化只是防止“进程崩溃/断电”丢数据，磁盘损坏、误删文件、机房故障依旧会丢。真正的备份要把 RDB / AOF 目录定期同步到异地或对象存储。