redis持久化RDB与AOF的对比

极客李华

已于 2024-04-25 23:10:21 修改

阅读量673

点赞数 19

分类专栏： redis 文章标签： redis bootstrap git

于 2024-04-25 21:20:44 首次发布

本文链接：https://blog.csdn.net/qq_51447496/article/details/138199718

版权

redis 专栏收录该内容

37 篇文章 2 订阅

订阅专栏

redis持久化RDB与AOF的对比

Redis提供了两种主要的持久化机制：RDB（Redis Database）和AOF（Append Only File）。

RDB持久化

RDB是通过创建数据库状态的快照来实现持久化的。在指定的时间间隔内，如果指定数量的键被修改，Redis就会创建一个快照并保存到磁盘上。这个快照可以手动触发，也可以根据配置文件中设置的规则自动触发。RDB文件是二进制格式，通常较小，恢复速度快。

在Redis中，RDB持久化可以通过两种不同的方式触发：

手动触发：使用SAVE或BGSAVE命令立即创建快照。
自动触发：根据redis.conf配置文件中save指令指定的规则自动进行。

下面是使用redis-cli命令行工具来演示RDB持久化的命令：

手动触发RDB持久化

使用SAVE命令（会阻塞Redis处理其他命令，直到快照完成）：
```
127.0.0.1:6379> SAVE
OK
```
使用BGSAVE命令（会创建一个子进程来处理快照，不阻塞主进程）：
```
127.0.0.1:6379> BGSAVE
Background saving started
```
注意：BGSAVE命令的输出不会立即显示“OK”，而是告诉你快照操作已经在后台开始。

自动触发RDB持久化

在redis.conf配置文件中，可以通过设置如下规则来自动触发RDB持久化：

save 900 1      # 如果至少有1个键被改变，则每900秒保存一次
save 300 10     # 如果至少有10个键被改变，则每300秒保存一次
save 60 10000   # 如果至少有10000个键被改变，则每60秒保存一次

这些规则意味着，根据键的修改次数和时间间隔，Redis会自动执行BGSAVE来创建数据快照。

要应用配置文件中的持久化设置，需要重启Redis服务器或者使用CONFIG REWRITE命令来重写配置（如果配置文件中设置了可覆盖选项）：

127.0.0.1:6379> CONFIG REWRITE
OK
CONFIG REWRITE命令将当前的配置写入到配置文件中，不重启Redis服务。

查看当前RDB持久化配置

可以使用CONFIG GET命令查看当前的RDB持久化配置：

127.0.0.1:6379> CONFIG GET save
1) "save"
2) 1) "900"
   2) "1"
3) 1) "300"
   2) "10"
4) 1) "60"
   2) "10000"

这表示当前的自动快照规则与上面提到的配置相符。

RDB持久化的快照文件默认命名为dump.rdb，存储在Redis服务器的工作目录中。这个二进制文件可以在Redis重启时被加载，以恢复数据。由于RDB文件是经过压缩的，它通常体积较小，恢复速度较快。

AOF持久化

AOF持久化记录了服务器接收到的每一个写操作命令，并将这些命令追加到文件的末尾。在Redis重启时，它会重放这些命令来重建原始数据。AOF文件是文本格式，可以提供更好的持久性保证，但是文件大小通常会比RDB大，且恢复速度慢。

AOF持久化在Redis中通过记录每个写操作命令来实现。以下是演示如何在Redis中启用AOF持久化、如何查看当前AOF状态以及如何执行AOF重写的命令：

启用AOF持久化

要启用AOF持久化，你需要在redis.conf配置文件中设置appendonly为yes。你也可以使用CONFIG SET命令动态地修改此配置：

127.0.0.1:6379> CONFIG SET appendonly yes
OK

查看当前AOF持久化配置

要查看当前的AOF持久化配置，可以使用CONFIG GET命令：

127.0.0.1:6379> CONFIG GET appendonly
1) "appendonly"
2) "yes"

AOF文件同步策略

Redis提供了几种不同的AOF文件同步策略，可以通过appendfsync配置项设置。以下是可用的选项：

always：每次写操作后都同步，数据安全性最高，但可能会影响性能。
everysec：每秒同步一次，这是默认设置，提供性能和数据安全性的平衡。
no：让系统自行决定何时同步，可能会丢数据，但性能最好。

查看当前的AOF同步策略：

127.0.0.1:6379> CONFIG GET appendfsync
1) "appendfsync"
2) "everysec"

修改AOF同步策略：

127.0.0.1:6379> CONFIG SET appendfsync always
OK

执行AOF重写

AOF重写（AOF rewrite）是优化AOF文件的过程，它会创建一个新的AOF文件，其中包含重建当前数据集所需的最少命令集合。这可以减少AOF文件的大小并提高恢复速度。

要触发AOF重写，可以使用BGREWRITEAOF命令：

127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started

请注意，和BGSAVE类似，BGREWRITEAOF也是在后台执行，不会阻塞Redis服务器。

查看AOF重写进度

Redis提供了INFO命令，通过它可以查看AOF重写的进度：

127.0.0.1:6379> INFO Persistence
# Persistence
aof_rewrite_in_progress:0
aof_last_rewrite_time_sec:1623687198
aof_current_size:5639234
aof_base_size:5639234
aof_pending_rewrite:0
aof_buffer_length:0
aof_rewrite_buffer_length:0
...

在输出中，aof_rewrite_in_progress字段将显示AOF重写是否正在进行（0表示没有，1表示是）。

RDB与AOF的区别

特性	RDB	AOF
持久化方式	快照（Snapshot）	日志（Log）
文件格式	二进制（Binary）	文本（Text）
文件大小	通常较小（Compact）	通常较大（Bulkier）
启动加载速度	快（Faster）	慢（Slower）
数据安全性	可能丢失数据（取决于快照频率）	高安全性（除非配置了不同步磁盘）
磁盘I/O	快照创建时较高（Snapshot creation can be I/O intensive）	持续较低（Lower I/O as commands are appended）
配置	`save <seconds> <changes>`	`appendonly yes` 和 `appendfsync` 选项
适用场景	数据不频繁更新，对数据完整性要求不高的场景	数据更新频繁，对数据完整性要求高的场景
恢复速度	快速（Quick to restore）	慢（Slower to restore）
缺点	可能会丢失数据	文件可能会变得很大，影响性能
混合持久化	Redis 4.0+ 支持RDB和AOF的混合持久化，提高数据安全性的同时加快启动速度	Redis 4.0+ 支持RDB和AOF的混合持久化，提高数据安全性的同时加快启动速度