RDB 与 AOF 怎么选
RDB 是周期全量快照，文件紧凑、恢复快，适合冷备、迁移与灾备，但丢数据窗口取决于快照间隔；AOF 记录写命令并配合 appendfsync everysec，把丢失窗口压到约一秒，代价是文件更大、恢复要回放命令。生产主流做法是两者同开：AOF 保在线数据安全，RDB 承担备份与快速拉起。
基本信息
| RDB 触发 | BGSAVE、save 规则、主从全量同步 |
|---|---|
| AOF 开关 | appendonly yes，Redis 7.0 起使用多文件结构 |
| 刷盘策略 | appendfsync always / everysec / no |
| 重写控制 | auto-aof-rewrite-percentage 与 min-size |
| 目录约定 | 7.0 起 AOF 位于 appendonlydir 目录 |
典型使用场景
- 电商缓存与队列：AOF everysec 作为数据安全底线
- 每日冷备：定时把 RDB 文件归档到对象存储
- 主从首次同步：从库接入时由主库生成并传输 RDB
- 版本升级与迁移：RDB 比 AOF 回放更快，适合快速拉起
- 故障演练：验证只开 RDB 时能接受的丢失窗口到底有多大
- 成本权衡：写密集高吞吐实例评估双份写盘对磁盘 IO 的影响
推荐组合（redis.conf 片段）
推荐组合（redis.conf 片段）
appendonly yes
appendfsync everysec
save 900 1
save 300 10
stop-writes-on-bgsave-error yes
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 256mb
# 验证命令：
# redis-cli INFO persistence | grep -E 'aof_enabled|rdb_last_bgsave_status|aof_last_write_status'
# redis-cli CONFIG GET appendfsync
# redis-cli INFO stats | grep -E 'rdb_changes_since_last_save'维度对比
| 维度 | RDB | AOF |
|---|---|---|
| 数据粒度 | 快照点，丢窗口内全部变更 | everysec 最多丢约 1 秒 |
| 文件大小 | 紧凑，通常明显更小 | 较大，7.0 混合重写后缩小 |
| 恢复速度 | 快，直接加载内存镜像 | 较慢，需要逐条回放命令 |
| 写入开销 | fork 加 COW，周期性尖峰 | 追加写，重写时额外占用 IO |
| 常见用途 | 冷备、迁移、灾备 | 在线实例的数据安全底线 |
只开 RDB 的实例，宕机丢失窗口可达数分钟；只开 AOF 的大库恢复慢且重写压力大。两者同开是主流平衡点，代价是双重写盘开销。
Redis 7.0 起 AOF 采用多文件结构（manifest 加基础文件加增量文件），备份必须整个 appendonlydir 目录一起拷贝；只拷其中一个文件会得到无法恢复的数据。
重写与快照期间会额外占用内存和 IO：fork 加写时复制让内存峰值可能接近数据量翻倍，AOF 重写还会与主线程争抢磁盘带宽；容量规划要按数据量加峰值开销预留，而不是按平日用量。