Redis 持久化深度解析：RDB 与 AOF 的机制、选型与生产最佳实践

Redis 虽然以内存数据库著称，但持久化能力是它能在生产环境中承担缓存、会话、计数等关键角色的基础。一旦进程崩溃、机器宕机或需要数据恢复，RDB 与 AOF 这两套持久化机制决定了你能否把数据找回来、以及找回的速度。本文从底层机制切入，给出生产环境下的选型与调优建议。

RDB：内存快照

RDB（Redis Database）把某一时刻的整个数据集写入一个二进制快照文件（默认 dump.rdb）。它的核心特点是恢复速度快——直接加载二进制文件，不需要重放任何操作日志，适合作为灾难恢复的冷备份。

# redis.conf 中的 RDB 触发条件
save 900 1     # 900 秒内至少有 1 次写操作
save 300 10    # 300 秒内至少有 10 次写操作
save 60 10000  # 60 秒内至少有 10000 次写操作

RDB 的保存机制采用写时复制（Copy-On-Write，COW）：主进程 fork 出子进程，子进程把内存快照写入临时文件，写完后原子性地 rename 替换旧快照。这个过程中主进程仍可继续服务读写请求。

AOF：追加写日志

AOF（Append Only File）把每一条写命令追加到日志文件，通过重放日志重建数据集。它最大的优点是数据更完整——可以配置成每写一条命令就 fsync 一次，实现最多丢失一条命令的可靠性。

# appendfsync 三种策略
appendfsync always   # 每写一条命令都 fsync，最安全但最慢
appendfsync everysec # 每秒 fsync 一次，折中方案（默认）
appendfsync no       # 交给操作系统决定，最快但最不可靠

AOF 的缺点是需要重放日志，恢复速度比 RDB 慢；且日志会持续膨胀，需要定期做 AOF 重写（rewrite）压缩成紧凑格式。

RDB 与 AOF 的对比

混合持久化：生产推荐方案

Redis 4.0 引入了混合持久化（aof-use-rdb-preamble yes）：AOF 文件的头部嵌入一段 RDB 快照，之后的写入以 AOF 格式追加。加载时先快速读取 RDB 快照部分，再重放增量日志，兼具两者的优点——既快又不丢数据。

生产调优建议

首先，生产环境务必同时开启 RDB 与 AOF：RDB 作为快照备份用于快速恢复，AOF 用于保证数据不丢。其次，定期执行 BGREWRITEAOF 或依赖自动 rewrite 压缩 AOF 体积。最后，把 RDB 文件通过异地备份（如云存储）做离线冗余，避免单机磁盘损坏导致的数据永久丢失。

当数据量很大时，fork 的 COW 过程会占用大量内存并短暂阻塞主线程，可通过 fork 频率、repl-backlog 等参数权衡。对缓存类数据（可容忍丢失）可只用 RDB；对订单、积分等不可丢数据，务必开启 AOF everysec 或 always。