Redis 持久化两种方式：RDB 与 AOF 怎么选

发布时间:2026-10-11 09:18

## 两种机制是什么 Redis 的数据默认在内存里，进程一退出数据就没了，持久化机制决定断电重启后还能找回多少。RDB 是定时快照：隔一段时间或满足条件时把整个数据集以二进制形式写到磁盘，文件紧凑、恢复快，但两次快照之间的数据在故障时会丢。AOF 是追加日志：每条写命令执行后追加记录到文件，重启时重放命令恢复数据，丢多少取决于刷盘策略，最多一秒，代价是文件更大、恢复更慢。 ## 背后的取舍 两种机制对应两种故障观。RDB 像定时拍照，恢复就是加载一张照片，速度快、文件小、对日常性能影响小，适合"丢了最近几分钟也能接受"的数据。AOF 像行车记录仪，appendfsync everysec 策略下每秒强制刷盘一次，故障窗口压到一秒，适合"一条都不能丢"的数据，代价是磁盘写入压力大、文件膨胀需要后台重写压缩，重写期间的内存与 IO 波动在写流量大的实例上要提前留意。两者可以同时开：AOF 保下限，RDB 保恢复速度与备份便利，Redis 重启时优先用 AOF 恢复。 ## 最小实操 配置文件里最常用的三处：save 规则定义 RDB 触发条件，比如 900 秒内至少 1 次修改、60 秒内至少 1 万次修改；appendonly yes 打开 AOF；appendfsync everysec 是稳妥的刷盘策略： ``` save 900 1 appendonly yes appendfsync everysec ``` 改完重启实例，用 info persistence 确认 rdb_last_bgsave_status 与 aof_last_write_status 都是 ok。手动做一次 bgsave 并把 dump 文件复制到备份机，这是最简单的异地备份形态。 ## 常见错误与选型建议 最常见的错配是拿 Redis 当唯一存储却只开 RDB，快照间隔内的写入说丢就丢，业务方往往完全不知情。反向的错配是纯缓存场景强开 AOF，白白承受写放大，缓存丢了重建即可，日志反而拖慢故障恢复速度。选型一句话：缓存用 RDB 或干脆不持久化；当队列、计数器、去重集合这类有状态数据用，AOF 必开，everysec 起步。在顺云的云服务器上自建 Redis 时，还要留意内存上限与淘汰策略的配合，别让持久化与内存淘汰互相打架。重启恢复时间也要预估：AOF 文件很大的实例起来可能要几分钟，主从架构下先让从库顶住流量再滚动重启。