1.概述
在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的触发规则，格式为：
bash
save <seconds> <changes> [<seconds> <changes> ...]表示 "在 seconds 秒内，若数据修改次数达到 changes 次，则触发 RDB"。
默认配置如下：
bash
# 3600秒(1小时)内修改1次、300秒内修改100次、60秒内修改10000次，满足任一条件即触发RDB
save 3600 1
save 300 100
save 60 100002.手动触发：主动备份场景
手动触发主要通过save、bgsave指令实现：
save命令 ：由主进程直接生成 RDB，期间会阻塞所有客户端请求（线上不推荐使用，会阻塞请求导致业务中断）；
bgsave命令：主进程 fork 子进程生成 RDB，主进程本身不阻塞（线上手动触发的首选指令）
3.RDB核心配置文件
bash
#指定 RDB 文件的名称，默认为dump.rdb
dbfilename dump.rdb
#指定 RDB 文件的保存路径，默认是 Redis 的启动目录（建议改为绝对路径，如/var/redis/）
dir ./
#是否对 RDB 文件进行压缩（默认开启，用 CPU 开销换取磁盘空间，关闭可提升快照速度）
rdbcompression yes
#是否对 RDB 文件进行校验（默认开启，通过 CRC64 算法确保文件完整性，关闭可提升加载速度）
rdbchecksum yes 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
bash
# 启用AOF（默认no）
appendonly yes
# AOF文件名称，默认appendonly.aof
appendfilename "appendonly.aof"
# AOF文件保存路径，与RDB一致
dir ./ 2.刷盘策略
appendfsync定义了 AOF 缓冲区的命令何时写入磁盘，有三种可选值：
| 值 | 解释 |
|---|---|
| always | 每执行一条写命令，立即将缓冲区内容写入到磁盘，数据安全性高，IO频繁 |
| everysec | 每秒将缓冲区内容写入磁盘一次，数据安全性一般，性能适中 |
| no | 由操作系统决定何时写入磁盘，默认30秒刷盘一次，数据安全性低，性能较高 |
3.日志重写规则
AOF 重写同样支持自动触发和手动触发，自动触发通过auto-aof-rewrite-percentage和auto-aof-rewrite-min-size配置实现：
bash
auto-aof-rewrite-percentage 100 # 当AOF文件大小比上次重写后增大100%（即翻倍）时触发
auto-aof-rewrite-min-size 64mb # 当AOF文件大小至少达到64MB时才触发（避免小文件频繁重写）手动触发：执行bgrewriteaof命令，主进程 fork 子进程完成重写，不阻塞业务（和bgsave类似）。
4.AOF优缺点
优点：
数据一致性高： 可通过appendfsync always实现 "数据零丢失"，或everysec实现 "最多丢失 1 秒数据"，满足高一致性需求；
日志可读性强： 由于AOF 文件是一个易于读取和理解的文本文件，可以方便地进行数据恢复、备份和分析；
可靠性高： 记录了Redis执行的所有写操作，可以提供更可靠的数据持久性，避免数据丢失。
缺点：
恢复速度慢： 恢复数据时需要执行大量的写命令，因此恢复速度相对较慢；
文件体积大： 即使经过重写，AOF 文件体积通常仍大于 RDB 文件，占用更多磁盘空间；
性能开销较高： 每次写操作都需要追加到 AOF 文件中，可能会导致磁盘 I/O 的负载增加。
2.3 RDB与AOF对比
| RDB | AOF | |
|---|---|---|
| 优点 | 文件体积小，恢复速度相对较快，对系统性能影响较小 | 可读性高，数据安全性高，支持实时恢复 |
| 缺点 | 数据安全性相对较低，可读性低，无法满足大规模、对数据备份要求高的场景 | 文件体积较大，恢复速度相对较慢，对系统性能有一定影响 |
| 适用场景 | 对数据安全性要求相对较低，希望快速地进行数据恢复 | 对数据安全性要求较高，而且可以接受稍慢一些的恢复速度 |
3.小结
1.RDB持久化方式能够在指定的时间间隔内对数据进行快照存储；
2.AOF持久化方式记录每次对服务器写的操作，服务器重启时会重新执行这些命令来恢复原始的数据；
3.RDB和AOF可同时开启，Redis重启时会优先载入AOF文件来恢复原始数据，因为通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整；
4.一般情况下，RDB文件只用作后备用途，建议只在slave机器上持久化RDB文件，并且只要15分钟备份一次就够了；
5.如果只做缓存，只希望数据在服务器运行的时候存在，其实不需要持久化操作。
4.参考文献
1.https://www.cnblogs.com/SLchuck/p/19101605