Redis中RDB与AOF的区别及说明_Redis

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 缓冲区的命令何时写入磁盘，有三种可选值：

值	解释
always	每执行一条写命令，立即将缓冲区内容写入到磁盘，数据安全性高，io频繁
everysec	每秒将缓冲区内容写入磁盘一次，数据安全性一般，性能适中
no	由操作系统决定何时写入磁盘，默认30秒刷盘一次，数据安全性低，性能较高

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

	rdb	aof
优点	文件体积小，恢复速度相对较快，对系统性能影响较小	可读性高，数据安全性高，支持实时恢复
缺点	数据安全性相对较低，可读性低，无法满足大规模、对数据备份要求高的场景	文件体积较大，恢复速度相对较慢，对系统性能有一定影响
适用场景	对数据安全性要求相对较低，希望快速地进行数据恢复	对数据安全性要求较高，而且可以接受稍慢一些的恢复速度