理解与权衡Redis的两种持久化方式（RDB-AOF）

最新推荐文章于 2024-09-23 13:14:09 发布

ATFWUS

最新推荐文章于 2024-09-23 13:14:09 发布

阅读量1.1w

点赞数 47

分类专栏：【Redis专栏】文章标签： redis 数据库数据库持久化 rdb aof

本文为ATFWUS原创，允许转载，但请附上作者署名和本文链接

本文链接：https://blog.csdn.net/ATFWUS/article/details/120549690

版权

【Redis专栏】专栏收录该内容

1 篇文章 2 订阅

订阅专栏

在复习Redis相关知识时，系统整理了Redis持久化相关的知识点。

前言

Redis作为一个内存数据库，数据都保存在内存中，但是内存的数据是容易发生丢失的。Redis提供了持久化的机制，RDB(Redis DataBase)和AOF(Append Only File)。
下面Redis将数据保存到磁盘上的五个步骤：
在这里插入图片描述前面三个步骤是Redis完成，后面两个步骤是操作系统完成。
所有和持久化相关的配置都在redis.conf中。

Redis官方对持久化机制的介绍见：https://redis.io/topics/persistence

下面翻译一下Redis官网对持久化机制的一个大体介绍：
在这里插入图片描述
Redis提供了一系列不同的持久性机制：

RDB（Redis Database）：RDB持久化在指定的时间间隔执行数据集的快照。
AOF（Append Only File）：AOF持久化记录服务器接收到的每个写入操作，这些操作将在服务器启动时再次执行，重建原始数据集。命令使用与Redis协议本身相同的格式，以仅附加的方式记录。当日志变得太大时，Redis能够在后台重写日志。
No persistence ：如果希望，可以完全禁用持久化，只要服务器在运行，数据就一直存在。
RDB + AOF：可以在同一个实例中组合AOF和RDB。注意，在这种情况下，当Redis重新启动时，AOF文件将用于重建原始数据集，因为它保证是最完整的。

最重要的事情是理解RDB和AOF持久性之间的不同权衡。

Redis持久化之RDB（Redis DataBase）

1.理解RDB机制

在指定的时间间隔内将内存中的数据集快照写入磁盘（Snapshot快照），它恢复时是将快照文件直接读到内存里。

Redis 会单独fork一个子进程来进行持久化：

首先将数据写入到一个临时文件中，等所有持久化过程全部结束了，再用临时文件替换上次持久化好的文件。
整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。
如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
但是最后一次持久化后的数据可能丢失。

在这里插入图片描述

2.RDB触发方式

save触发方式

执行save命令时只管保存，其它不管，全部阻塞。
该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。

bgsave触发方式

执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。阻塞只发生在fork阶段，一般时间很短。
可以通过lastsave命令获取最后一次成功执行快照的时间。
在这里插入图片描述

自动触发方式

自动触发是由配置文件来完成的。具体配置如下：

# save：用来配置触发 Redis的 RDB 持久化条件，也就是什么时候将内存中的数据保存到硬盘。
# “save m n” 表示m秒内数据集存在n次修改时，自动触发bgsave。
# 如果不需要持久化，可以注释掉所有的 save 行来停用保存功能。
# 默认配置如下：
save 900 1 # 表示900 秒内如果至少有 1 个 key 的值变化，则保存
save 300 10
save 60 10000


# dbfilename ：设置快照的文件名，默认是 dump.rdb
dbfilename dump.rdb

# dir：设置快照文件的存放路径，这个配置项是一个目录
dir ./

# 当Redis无法写入磁盘的话，直接关掉Redis的写操作。
# 推荐yes
stop-writes-on-bgsave-error yes

# 对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。
# 如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能。
# 推荐yes
rdbcompression yes

# 在存储快照后，还可以让redis使用CRC64算法来进行数据校验，
# 但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能
# 推荐yes
rdbchecksum yes

动态停止RDB的方式：

#save后给空值，表示禁用保存策略
redis-cli config set save ""

3.RDB的优劣势

优势

适合大规模的数据恢复
对数据完整性和一致性要求不高更适合使用
节省磁盘空间
恢复速度快

劣势

Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑。
虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

Redis持久化之AOF（Append Only File）

1.理解AOF机制

以日志的形式来记录每个写操作（增量保存机制），将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据。通俗理解就是日志记录。

redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

在这里插入图片描述

持久化流程：

（1）客户端的请求写命令会被append追加到AOF缓冲区内；
（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；
（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

2.重写（Rewrite）

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。
使用如下命令：

bgrewriteaof

重写原理

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写。先写临时文件最后再rename。
redis4.0版本后，重写的原理是：将rdb对的快照，以二进制的形式附在新的aof的头部，作为已有的历史数据，替换掉原来的流水账操作。

重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。

# 设置重写的基准值，文件达到100%时开始重写（文件是原来重写后文件的2倍时触发）
auto-aof-rewrite-percentage
# 设置重写的基准值，最小文件64MB。达到这个值开始重写。
auto-aof-rewrite-min-size

# 如果值为yes 不写入aof文件 只写入缓存 用户请求不会阻塞 在这段时间如果宕机会丢失这段时间的缓存数据。数据安全性降低 性能提高
# 如果值为no,会把数据写入磁盘，但是遇到重写操作，可能会发生阻塞。 数据安全性提高 性能降低
no-appendfsync-on-rewrite yes

重写流程

当使用bgrewriteaof命令后，重写流程如下：
（1）判断是否有bgsave和bgrewriteaof还未结束，如果有，则等待其结束再执行。
（2）主进程fork出子进程进行重写操作。
（3）子进程将redis内存中数据保存到临时文件，与此同时，新的客户端写请求会写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及文件生成的过程中新的数据修改操作不会丢失。
（4）子进程写完新的AOF文件后，通知父进程。
（5）主进程把aof_rewrite_buf中的数据写入到心的AOF文件。
（6）使用新的AOF文件覆盖旧的AOF文件，完成该次的AOF重写操作。

在这里插入图片描述

3.AOF同步频率

# 始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好
appendfsync always
# 每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
appendfsync everysec
# redis不主动进行同步，把同步时机交给操作系统。
appendfsync no

同步频率	优点	缺点
always	不会丢失数据	IO开销大
everysec	IO开销低	丢失1s数据
no	无额外IO开销	容易丢失数据

4.相关配置说明

AOF默认不开启，修改配置文件开启。

# 改为yes开启
appendonly no

可以在redis.conf中配置文件名称，默认为 appendonly.aof
AOF文件的保存路径，同RDB的路径一致。
AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。

AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）

5.AOF的优劣势

优势

AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。
AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。
可读的日志文本，通过操作AOF文件可以处理误操作。
AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不容易破损。

劣势

比起RDB占用更多的磁盘空间。
恢复备份速度要慢。
每次读写都同步的话，有一定的性能压力。
存在个别Bug，造成恢复不完全。

RDB和AOF的权衡

Redis官网的建议
在这里插入图片描述

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.
Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
同时开启两种持久化方式
- 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据, 因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？
- 建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。
如果对数据不敏感，可以选单独用RDB。