4. Redis 持久化机制：RDB快照原理与配置、AOF日志重写机制、混合持久化、生产选型建议

Redis 作为内存数据库，其数据安全性高度依赖持久化机制。在生产环境中，持久化不仅用于数据恢复，更是保障缓存一致性与削峰场景下数据不丢失的基石。本章深入剖析 RDB、AOF 及混合持久化的核心原理、配置参数与生产选型策略。

4.1 RDB 快照原理与配置

RDB（Redis Database）通过创建内存数据的二进制快照文件（dump.rdb）实现持久化。其核心机制基于操作系统的 fork() 系统调用与 写时复制（Copy-On-Write, COW） 技术。

4.1.1 触发方式

  • 手动触发：SAVE（同步阻塞，不推荐生产使用）与 BGSAVE（异步后台 fork 子进程执行）。
  • 自动触发：通过 save 配置指令定义策略，如 save 900 1（900 秒内至少 1 次修改）、save 300 10、save 60 10000。
  • 其他触发：主从全量复制、SHUTDOWN、FLUSHALL（需配置）等。

4.1.2 核心配置参数

配置项默认值说明
save ""无禁用 RDB 持久化
stop-writes-on-bgsave-erroryesBGSAVE 失败时是否停止写入
rdbcompressionyes是否对 RDB 文件进行 LZF 压缩
rdbchecksumyes是否在文件末尾写入 CRC64 校验和
dbfilenamedump.rdbRDB 文件名
dir./RDB 文件存储目录

4.1.3 写时复制（COW）流程

  1. 父进程执行 BGSAVE，调用 fork() 创建子进程。
  2. 子进程共享父进程的内存页，开始将数据写入临时 RDB 文件。
  3. 父进程继续处理客户端请求，当需要修改某个内存页时，触发 COW：复制该页到新内存地址，父进程修改副本，子进程仍读取原始页。
  4. 子进程完成快照写入后，原子替换旧 RDB 文件。
生产注意：COW 机制下，若写入量极大，父进程会复制大量内存页，导致内存占用翻倍。建议预留 50% 以上内存余量，并监控 fork() 耗时（latest_fork_usec）。
RDB 写时复制（COW）流程 父进程（Redis 主） 处理客户端请求 子进程（BGSAVE） 写入临时 RDB 文件 共享内存页 复制内存页 fork() 创建子进程 读 读 写时复制 写入临时 RDB 文件 temp.rdb 原子 rename dump.rdb

4.2 AOF 日志重写机制

AOF（Append Only File）以日志形式记录每次写操作指令，恢复时逐条执行。其核心优势是数据安全性高（可配置 fsync 策略），但文件体积会持续增长，需要 AOF 重写（Rewrite） 机制进行瘦身。

4.2.1 AOF 配置与 fsync 策略

配置项默认值说明
appendonlyno是否开启 AOF
appendfilenameappendonly.aofAOF 文件名
appendfsynceverysecfsync 策略：always / everysec / no
auto-aof-rewrite-percentage100AOF 文件增长百分比触发重写
auto-aof-rewrite-min-size64mbAOF 文件最小重写大小
fsync 策略选型：
always：每次写入都 fsync，最安全但性能最差（约 200 ops/s）。
everysec：每秒 fsync 一次，兼顾性能与安全（推荐生产使用）。
no：由操作系统决定刷盘时机，性能最好但可能丢失最近几秒数据。

4.2.2 AOF 重写原理

AOF 重写并非读取旧 AOF 文件，而是基于当前内存中的数据状态，生成恢复当前数据集所需的最小指令集。流程如下：

  1. Redis 主进程 fork 出子进程，子进程根据当前内存快照生成新的 AOF 文件。
  2. 重写期间，主进程继续处理写请求，并将写指令同时写入 AOF 重写缓冲区（防止丢失增量数据）。
  3. 子进程完成新 AOF 文件生成后，通知主进程。
  4. 主进程将重写缓冲区中的增量指令追加到新 AOF 文件末尾。
  5. 原子替换旧 AOF 文件为新文件。
避坑：AOF 重写期间若写入量巨大，重写缓冲区可能膨胀，导致主进程内存占用飙升。建议监控 aof_rewrite_buffer_length，并合理设置 client-output-buffer-limit。
AOF 重写流程 主进程 处理写请求 子进程（重写） 基于内存快照生成新 AOF 旧 AOF 文件 重写缓冲区 新 AOF 文件 最终 AOF 文件 fork() 继续追加 增量指令 基于快照生成 追加增量 原子替换

4.3 混合持久化

Redis 4.0 引入混合持久化（aof-use-rdb-preamble），结合 RDB 的快照速度与 AOF 的数据安全性。AOF 文件头部包含一个 RDB 格式的全量数据快照，后续追加增量 AOF 日志。

4.3.1 混合持久化优势

  • 加载速度：重启时直接加载 RDB 快照，比逐条执行 AOF 日志快数倍。
  • 数据安全：RDB 快照之后的增量数据由 AOF 日志保证，丢失窗口可控制在 1 秒内（everysec 策略）。
  • 文件体积：相比纯 AOF，混合持久化文件更小，因为 RDB 部分采用二进制压缩。

4.3.2 配置与启用

# redis.conf
appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes    # 开启混合持久化
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
生产建议：混合持久化是当前 Redis 生产环境的主流选择。它兼顾了 RDB 的快速恢复与 AOF 的低数据丢失风险。建议配合 everysec fsync 策略，在性能与安全之间取得平衡。

4.4 生产选型建议

持久化选型需根据业务对 数据安全性、恢复速度、性能开销 的综合要求决定。以下为常见场景的选型矩阵：

业务场景推荐方案理由
缓存（可丢失）RDB 或关闭持久化追求极致性能，数据可接受分钟级丢失
数据库（不可丢失）混合持久化（AOF+RDB）秒级丢失窗口，快速重启恢复
削峰队列（高写入）混合持久化 + everysec平衡写入性能与数据安全，避免 always 策略的 fsync 瓶颈
主从架构主库 RDB + 从库 AOF主库减少持久化开销，从库保证数据安全
内存紧张（< 4GB）RDB + 关闭 AOF避免 AOF 重写期间的内存翻倍风险

4.4.1 关键监控指标

  • rdb_last_bgsave_time_sec：上次 BGSAVE 耗时，超过 10 秒需关注。
  • rdb_current_bgsave_time_sec：当前 BGSAVE 已执行时间。
  • aof_current_size 与 aof_base_size：监控 AOF 文件增长趋势。
  • aof_rewrite_buffer_length：重写缓冲区长度，过大表示写入压力高。
  • latest_fork_usec：fork 耗时，超过 1 秒可能影响主进程响应。
生产避坑：
1. 不要同时使用 SAVE 与 BGSAVE，SAVE 会阻塞所有请求。
2. 大实例（> 10GB）的 fork 操作可能耗时数秒，建议设置 repl-backlog-size 足够大，避免主从同步中断。
3. 开启 AOF 后，务必配置 auto-aof-rewrite-percentage 与 auto-aof-rewrite-min-size，防止 AOF 文件无限增长。
4. 混合持久化下，AOF 重写期间仍会生成 RDB 快照，内存开销与纯 RDB 类似，需预留足够内存。

4.4.2 持久化方案对比总结

特性RDBAOF混合持久化
数据丢失窗口分钟级（取决于 save 策略）秒级（everysec）或零（always）秒级（everysec）
恢复速度快（直接加载二进制快照）慢（逐条执行指令）快（加载 RDB 快照 + 少量 AOF）
文件体积小（压缩二进制）大（文本协议）中等（RDB 部分压缩）
写入性能影响低（fork + COW）中（fsync 频率影响）中（同 AOF）
内存开销高（COW 可能翻倍）低（重写时需缓冲区）高（重写时需 RDB 快照 + 缓冲区）
适用版本所有版本所有版本Redis 4.0+

在生产环境中，混合持久化 + everysec fsync 是兼顾性能与安全性的黄金组合。对于削峰场景，建议配合主从架构，主库开启混合持久化，从库作为数据冗余备份，进一步降低单点风险。

← 上一章 📖 返回目录 下一章 →