Redis 数据持久化实战：RDB 与 AOF 的取舍、配置与灾备方案

发布时间：2026-09-08 16:34 更新时间：2026-09-08 17:04 阅读量：0

很多运维新手把 Redis 当成"重启就清空"的缓存来用，直到某天服务器断电或进程被误杀，才发现里面存着会话、计数甚至订单状态，损失惨重。Redis 虽然以"内存数据库"闻名，但它本身就内置了把数据落盘的持久化能力，只是默认配置和业务形态未必适合你。搞清楚 RDB 与 AOF 这两套机制各自的脾气，才能为不同的数据场景选对方案。

持久化说白了就是把数据写到 SSD 这类稳定存储上。Redis 提供两条路：RDB 按指定时间间隔对整个数据集做"点对点快照"，生成一个紧凑的 dump.rdb 二进制文件；AOF 则把服务器收到的每一条写命令以 Redis 协议格式追加到日志文件里，重启时重放这些命令就能重建数据。两者也可以同时开启，互不冲突。

先看 RDB。它的最大优点是快照文件非常紧凑，只有一个文件，特别适合做备份和灾备：你可以每小时保留最近 24 小时的快照，每天再保留一个为期一个月的归档，出问题随时挑一个版本恢复。因为落盘工作由 fork 出的子进程完成，父进程完全不参与磁盘 I/O，所以对性能几乎无影响，重启大数据集也比 AOF 快得多。在复制场景下，从节点重启后还能利用 RDB 做部分重同步。但它有个先天短板：快照通常每隔几分钟才做一次，如果 Redis 在两次快照之间异常退出（比如断电、被 kill -9），这几分钟内的写入就全部丢失了。另外，数据集很大时 fork 可能让服务停顿几毫秒甚至一秒，在追求极致稳定的核心链路上需要留意。

RDB 的触发方式写在配置文件里，比如下面这条表示"60 秒内如果有至少 1000 个键发生变化就落盘一次"：

save 60 1000

也可以用 SAVE（前台阻塞）或 BGSAVE（后台）手动触发。快照生成走的是写时复制机制：主进程 fork 出子进程，子进程把数据写入临时 RDB 文件，写完后原子替换旧文件，整个流程对正在服务的请求没有影响。

再看 AOF。它比 RDB 耐久得多，关键在 fsync 策略：always 每次写命令都同步磁盘，最安全但极慢；everysec 每秒同步一次，兼顾性能与安全，这也是官方默认值，最坏只丢一秒数据；no 则完全交给操作系统决定何时刷盘，最快但最不安全。AOF 是纯追加写，没有磁盘寻道问题，即使断电导致日志尾部出现半截命令，也不会损坏整个文件，用自带的 redis-check-aof 工具就能修复。AOF 还有个贴心设计——自动重写：比如同一个计数器被自增了 100 次，日志里会有 100 条命令，而重建当前状态其实只需要一条，于是 Redis 会在后台把日志压缩成最少命令集，全程不影响对外服务。要开启 AOF 只需在配置里加一行：

appendonly yes
appendfsync everysec

AOF 的代价是文件通常比同等数据量的 RDB 大，且不同 fsync 策略下写入性能可能略低于 RDB。值得提醒的是，如果你的服务器之前只开 RDB，想平滑切换到 RDB+AOF 双开，千万别直接改配置重启——那会丢失数据。正确做法是先连上实例，用 CONFIG SET appendonly yes 在运行中开启 AOF，确认写入正常后，再把它写回配置文件（CONFIG REWRITE 或手工同步），下次重启才安全。官方还给出一个检验方法：重启前用 INFO persistence 观察 aof_rewrite_in_progress 是否为 0、aof_last_bgrewrite_status 是否为 ok，确保重写完成再动手。

那么生产环境到底怎么选？如果对数据安全的要求接近 PostgreSQL 那种级别，就 RDB 和 AOF 双开，让 AOF 保证完整性、RDB 提供快速备份与重启；如果业务能容忍灾难时丢几分钟数据，只开 RDB 就够了；如果 Redis 纯粹做缓存、上游数据库才是数据源，甚至可以把持久化整个关掉以追求极致性能。官方并不建议只开 AOF，因为偶尔一份 RDB 快照对排查 AOF 引擎自身的问题非常有价值。

最后是很多人忽略的备份纪律。RDB 文件一旦生成就不再被修改，备份时直接复制是安全的；官方建议用 crontab 每小时保留一份快照、每天做一次归档，并用 find 清理过期文件，同时至少每天把一份快照传输到异地的另一台机器或对象存储，别让备份和服务器死在同一个机房。AOF 备份在 Redis 7.0 之后要稍加小心：重写期间直接复制目录可能得到不完整文件，稳妥的做法是先 CONFIG SET auto-aof-rewrite-percentage 0 暂停自动重写，确认没有重写进行中再复制，完成后恢复原值。异地传输后一定要校验文件大小和 SHA1 摘要，并配一个"备份没更新就报警"的监控，否则灾难来了才发现备份早已失效，那才是最痛的教训。

继续阅读