Redis中RDB与AOF的区别及说明

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的触发规则，格式为：

save <seconds> <changes> [<seconds> <changes> ...]

表示 “在 seconds 秒内，若数据修改次数达到 changes 次，则触发 RDB”。

默认配置如下：

# 3600秒(1小时)内修改1次、300秒内修改100次、60秒内修改10000次，满足任一条件即触发RDB
save 3600 1
save 300 100
save 60 10000

2.手动触发：主动备份场景

手动触发主要通过save、bgsave指令实现：

• save命令：由主进程直接生成 RDB，期间会阻塞所有客户端请求（线上不推荐使用，会阻塞请求导致业务中断）； 
• bgsave命令：主进程 fork 子进程生成 RDB，主进程本身不阻塞（线上手动触发的首选指令）

3.RDB核心配置文件

#指定 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

# 启用AOF（默认no）
appendonly yes  
# AOF文件名称，默认appendonly.aof
appendfilename "appendonly.aof" 
# AOF文件保存路径，与RDB一致
dir ./  

2.刷盘策略

appendfsync定义了 AOF 缓冲区的命令何时写入磁盘，有三种可选值：

3.日志重写规则

AOF 重写同样支持自动触发和手动触发，自动触发通过auto-aof-rewrite-percentage和auto-aof-rewrite-min-size配置实现：

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对比

3.总结

1.RDB持久化方式能够在指定的时间间隔内对数据进行快照存储；

2.AOF持久化方式记录每次对服务器写的操作，服务器重启时会重新执行这些命令来恢复原始的数据；

3.RDB和AOF可同时开启，Redis重启时会优先载入AOF文件来恢复原始数据，因为通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整；

4.一般情况下，RDB文件只用作后备用途，建议只在slave机器上持久化RDB文件，并且只要15分钟备份一次就够了；

5.如果只做缓存，只希望数据在服务器运行的时候存在，其实不需要持久化操作。

以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。