在Redis的使用中，持久化是一个重要的特性，它将内存中的数据保存到硬盘上，以防止数据丢失。
Redis 提供了三种主要的持久化方式：AOF（Append Only File）、RDB（Redis DataBase）以及混合持久化（RDB和AOF）。
本文将详细介绍 AOF 和 RDB 的区别及配置方式，帮助读者更好地理解和选择合适的持久化方式。
2.RDB和AOF
2.1 RDB
2.1.1 RDB概念
RDB 持久化方式是 Redis 将当前内存中的数据快照（snapshot）保存到硬盘的过程。
这种方式是就是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为dump.rdb。其实就是每隔一段时间，Redis 会创建一个代表某一时刻的数据集的磁盘文件。
2.1.2 RDB工作原理（Copy-On-Write）
RDB 的生成过程依赖于操作系统的写时复制（COW）机制，这一机制确保了快照生成期间 Redis 依然能正常处理读写请求，不会阻塞业务。
具体流程如下：
- 1.触发快照生成：当满足预设条件时（时间到、达到修改次数阈值），Redis 主进程会fork 一个子进程（此时子进程与主进程共享同一块内存空间）；
- 2.子进程写入快照：子进程负责遍历内存中的所有数据，将其序列化后写入一个临时的.rdb 文件；
- 3.主进程正常服务：在子进程生成快照期间，主进程继续处理客户端的读写请求。若有数据被修改，操作系统会为该数据块创建一个副本，主进程修改副本数据，而子进程依然读取原始数据（避免快照被污染）；
- 4.替换旧快照：当子进程完成快照写入后，会用临时文件替换当前的.rdb 文件，至此一次 RDB 持久化完成。
2.1.3 RDB触发方式
1.自动触发：基于配置的"指定时间+修改次数"
在Redis 的配置文件（redis.conf）中，通过save指令定义RDB的触发规则，格式为：
1 |
|
表示 “在 seconds 秒内，若数据修改次数达到 changes 次，则触发 RDB”。
默认配置如下：
1 2 3 4 |
|
2.手动触发：主动备份场景
手动触发主要通过save、bgsave指令实现：
- save命令：由主进程直接生成 RDB，期间会阻塞所有客户端请求（线上不推荐使用，会阻塞请求导致业务中断）；
- bgsave命令：主进程 fork 子进程生成 RDB，主进程本身不阻塞（线上手动触发的首选指令）
3.RDB核心配置文件
1 2 3 4 5 6 7 8 |
|
4.RDB优缺点
优点：
- 恢复速度快：RDB 是二进制的全量快照，加载时无需解析复杂指令，仅需反序列化数据，适合大规模数据的快速恢复；
- 文件体积小：压缩后的 RDB文件体积远小于 AOF 文件，便于备份和传输；
- 对性能影响小：子进程负责生成快照，主线程仅在fork子进程时短暂阻塞（阻塞时间与内存大小相关，通常毫秒级），对业务读写影响低。
缺点：
- 数据一致性低： RDB获取的是“某一时间点快照”，若在两次快照间隔期间 Redis 宕机，则该时间段内修改的数据将全部丢失（例如：配置save 30 1000，则最多可能丢失30秒的数据）；
- 文件可读性性低：RDB 文件是一个二进制文件，并不是一个易于读取和理解的文本文件；
- 不适合实时备份：存在丢失数据的可能，适用于对数据一致性要求不高的业务。
2.2 AOF
2.2.1 AOF概念
AOF其实就是将每一个收到的写命令都通过write函数追加到文件中，当 Redis 需要恢复数据时，只需执行 AOF 文件中的命令就可以恢复到原来的状态。
这个文件有点像MySQL的binlog日志文件，只不过binlog日志文件是二进制，Redis的AOF生成的文件是文本格式。
2.2.2 AOF工作原理
1.命令追加
- 每当 Redis 执行一条写命令并成功处理后，会将该命令按照 Redis 协议格式追加到内存中的 “AOF 缓冲区”（避免直接写入磁盘，降低IO开销）。
- 2.文件刷盘AOF 缓冲区中的命令需要定期写入磁盘，刷盘策略由appendfsync配置决定。
3.日志重写
- 随着运行时间延长，AOF 文件会产生大量重复命令（如多次set同一个key）而变得异常庞大，占用大量磁盘空间，还会导致Redis重启恢复时间边长。
- Redis携带了 “日志重写” 机制，会生成一个包含 “当前内存数据最终状态” 的精简 AOF 文件，替换旧的AOF文件，能有效降低空间占用率、提升恢复效率。
例如：
- 若指定key的值经过多次set，最终是value3，AOF文件中记录了SET key value1、SET key
- value2、SET key value3三条命令，重写后只会保留SET key value3一条命令。
2.2.3 AOF配置
1.启用AOF
1 2 3 4 5 6 |
|
2.刷盘策略
appendfsync定义了 AOF 缓冲区的命令何时写入磁盘，有三种可选值：
| 值 | 解释 |
|---|---|
| always | 每执行一条写命令，立即将缓冲区内容写入到磁盘，数据安全性高，IO频繁 |
| everysec | 每秒将缓冲区内容写入磁盘一次，数据安全性一般，性能适中 |
| no | 由操作系统决定何时写入磁盘，默认30秒刷盘一次，数据安全性低，性能较高 |
3.日志重写规则
AOF 重写同样支持自动触发和手动触发，自动触发通过auto-aof-rewrite-percentage和auto-aof-rewrite-min-size配置实现：
1 2 |
|
手动触发：执行bgrewriteaof命令，主进程 fork 子进程完成重写，不阻塞业务（和bgsave类似）。
4.AOF优缺点
优点：
- 数据一致性高：可通过appendfsync always实现 “数据零丢失”，或everysec实现 “最多丢失 1 秒数据”，满足高一致性需求；
- 日志可读性强：由于AOF 文件是一个易于读取和理解的文本文件，可以方便地进行数据恢复、备份和分析；
- 可靠性高：记录了Redis执行的所有写操作，可以提供更可靠的数据持久性，避免数据丢失。
缺点：
- 恢复速度慢：恢复数据时需要执行大量的写命令，因此恢复速度相对较慢；
- 文件体积大：即使经过重写，AOF 文件体积通常仍大于 RDB 文件，占用更多磁盘空间；
- 性能开销较高：每次写操作都需要追加到 AOF 文件中，可能会导致磁盘 I/O 的负载增加。
