redis RDB & AOF 两种持久方案的优缺点

RDB advantages

RDB is a very compact single-file point-in-time representation of your Redis data. RDB files are perfect for backups. For instance you may want to archive your RDB files every hour for the latest 24 hours, and to save an RDB snapshot every day for 30 days. This allows you to easily restore different versions of the data set in case of disasters.
RDB is very good for disaster recovery, being a single compact file that can be transferred to far data centers, or onto Amazon S3 (possibly encrypted).
RDB maximizes Redis performances since the only work the Redis parent process needs to do in order to persist is forking a child that will do all the rest. The parent process will never perform disk I/O or alike.
RDB allows faster restarts with big datasets compared to AOF.
On replicas, RDB supports partial resynchronizations after restarts and failovers.

RDB disadvantages

RDB is NOT good if you need to minimize the chance of data loss in case Redis stops working (for example after a power outage). You can configure different save points where an RDB is produced (for instance after at least five minutes and 100 writes against the data set, you can have multiple save points). However you'll usually create an RDB snapshot every five minutes or more, so in case of Redis stopping working without a correct shutdown for any reason you should be prepared to lose the latest minutes of data.
RDB needs to fork() often in order to persist on disk using a child process. fork() can be time consuming if the dataset is big, and may result in Redis stopping serving clients for some milliseconds or even for one second if the dataset is very big and the CPU performance is not great. AOF also needs to fork() but less frequently and you can tune how often you want to rewrite your logs without any trade-off on durability.

AOF advantages

Using AOF Redis is much more durable: you can have different fsync policies: no fsync at all, fsync every second, fsync at every query. With the default policy of fsync every second, write performance is still great. fsync is performed using a background thread and the main thread will try hard to perform writes when no fsync is in progress, so you can only lose one second worth of writes.
The AOF log is an append-only log, so there are no seeks, nor corruption problems if there is a power outage. Even if the log ends with a half-written command for some reason (disk full or other reasons) the redis-check-aof tool is able to fix it easily.
Redis is able to automatically rewrite the AOF in background when it gets too big. The rewrite is completely safe as while Redis continues appending to the old file, a completely new one is produced with the minimal set of operations needed to create the current data set, and once this second file is ready Redis switches the two and starts appending to the new one.
AOF contains a log of all the operations one after the other in an easy to understand and parse format. You can even easily export an AOF file. For instance even if you've accidentally flushed everything using the FLUSHALL command, as long as no rewrite of the log was performed in the meantime, you can still save your data set just by stopping the server, removing the latest command, and restarting Redis again.

AOF disadvantages

AOF files are usually bigger than the equivalent RDB files for the same dataset.
AOF can be slower than RDB depending on the exact fsync policy. In general with fsync set to every second performance is still very high, and with fsync disabled it should be exactly as fast as RDB even under high load. Still RDB is able to provide more guarantees about the maximum latency even in the case of a huge write load.

Redis < 7.0

AOF can use a lot of memory if there are writes to the database during a rewrite (these are buffered in memory and written to the new AOF at the end).
All write commands that arrive during rewrite are written to disk twice.
Redis could freeze writing and fsyncing these write commands to the new AOF file at the end of the rewrite.

RDB优点
- 生成紧凑的单文件快照，适合定时备份（如每小时/每日归档）。
- 灾难恢复友好，支持远距离传输或云存储（如Amazon S3）。
- 高性能：主进程仅需fork子进程处理持久化，无磁盘I/O负担。
- 大数据集重启速度快于AOF，副本支持部分重新同步。
RDB缺点
- 可能丢失最后一次快照后的数据（默认配置下通常丢失5分钟以上数据）。
- 大数据集频繁fork()可能导致短暂服务延迟（毫秒级甚至秒级）。
AOF优点
- 高持久性：支持no/everysec/always三种fsync策略（默认每秒同步，性能仍高）。
- 易修复：日志追加写入，断电无损坏风险；redis-check-aof工具可修复异常文件。
- 自动后台重写AOF文件，压缩操作历史并保证数据安全。
AOF缺点
- 文件体积通常大于RDB。
- 性能略低于RDB（取决于fsync策略，关闭fsync时与RDB相当）。
AOF容错性
- 即使误操作（如FLUSHALL），只要未触发重写，可通过删除最后一条命令恢复数据。
版本差异（Redis <7.0）
- AOF重写期间写入操作会占用额外内存，且数据需两次写入磁盘。
- 重写结束时可能因同步新AOF文件导致短暂写入冻结。
RDB适用场景
- 需快速恢复、定期冷备或跨数据中心容灾的场景。
AOF适用场景
- 对数据完整性要求高，可容忍稍大文件体积和略低性能的场景。
持久化策略选择
- RDB与AOF互补：RDB用于基础备份，AOF确保增量数据安全。
- 根据数据容忍度（丢失时间窗口）和性能需求权衡选择。
运维建议
- 监控fork()延迟（尤其大数据集场景）。
- AOF重写期间关注内存与磁盘负载，Redis 7.0+优化了相关性能问题。