redis持久化AOF和RDB的区别及解决各个场景问题示例

什么是Redis持久化？

redis是一种内存数据库。持久化就是把内存的数据写到磁盘中去，防止服务宕机了内存数据丢失。

Redis提供了两种持久化策略: RDB（默认） 和AOF 。

RDB是指在指定的时间间隔内，把内存中的数据集快照写入磁盘。也就是只保留某个时间点的数据。
而AOF持久化会记录服务器接收的所有写操作命令，并且把这些命令追加到一个文件里面，持久化到磁盘上，在服务器启动的时候，通过重新执行这些命令来还原数据。

RDB快照

rdb是Redis DataBase缩写。

功能核心函数rdbSave(生成RDB文件)和rdbLoad（从文件加载内存）两个函数。

RBD持久化通过保存数据库中的键值对来记录数据库状态。

RBD配置文件的开启

save 900 1      // 900s内,有1条写入,则产生快照
save 300 1000   // 如果300秒内有1000次写入,则产生快照
save 60 10000  // 如果60秒内有10000次写入,则产生快照
(这3个选项都屏蔽，则rdb禁用)
stop-writes-on-bgsave-error yes  // 后台备份进程出错时,主进程是否停止写入
rdbcompression yes    // 导出的rdb文件是否压缩。建议没有必要开启，毕竟Redis本身就属于CPU密集型服务器，再开启压缩会带来更多的CPU消耗，相比硬盘成本，CPU更值钱。
rdbchecksum   yes //  导入rbd恢复数据时，是否验证rdb的完整性
dbfilename dump.rdb  //导出来的rdb文件名
dir ./  //rdb的放置路径

RDB原理

针对RDB方式的持久化，手动触发可以使用：

save：会阻塞当前Redis服务器，直到持久化完成，线上应该禁止使用。

bgsave：该触发方式会fork一个子进程，由子进程负责持久化过程，因此阻塞只会发生在fork子进程的时候。

而自动触发的场景主要是有以下几点：

• 根据我们的 save m n 配置规则自动触发；
• 从节点全量复制时，主节点发送rdb文件给从节点完成复制操作，主节点会触发 bgsave；
• 执行 debug reload 时；
• 执行 shutdown时，如果没有开启aof，也会触发。

由于 save 基本不会被使用到，我们重点看看 bgsave 这个命令是如何完成RDB的持久化的。

这里注意的是 fork 操作会阻塞，导致Redis读写性能下降。我们可以控制单个Redis实例的最大内存，来尽可能降低Redis在fork时的事件消耗。以及上面提到的自动触发的频率减少fork次数，或者使用手动触发，根据自己的机制来完成持久化。

BGSAVE命令执行时的服务器状态

首先,在BGSAVE命令执行期间,客户端发送的SAVE命令会被服务器拒绝,服务器禁止SAVE命令和BGSAVE命令同时执行是为了避免父进程(服务器进程)和子进程同时执行两个rdbSave调用,防止产生竞争条件。

其次,在BGSAVE命令执行期间,客户端发送的BGSAVE命令会被服务器拒绝,因为同时执行两个BGSAVE命令也会产生竞争条件。

最后, BGREWRITEAOF和BGSAVE两个命令不能同时执行:

• 如果BGSAVE命令正在执行,那么客户端发送的BGREWRITEAOF命令会被延迟到BGSAVE命令执行完毕之后执行。
• 如果BGREWRITEAOF命令正在执行,那么客户端发送的BGSAVE命令会被服务器拒绝。

因为BGREWRITEAOF和BGSAVE两个命令的实际工作都由子进程执行,所以这两个命令在操作方面并没有什么冲突的地方,不能同时执行它们只是一个性能方面的考虑-并
发出两个子进程,并且这两个子进程都同时执行大量的磁盘写入操作,这怎么想都不会是一个好主意。

AOF

Aof是Append-only file缩写。

AOF持久化通过保存redis服务器所执行的写命令来记录数据库状态。

AOF持久化的实现：

AOF持久化可分为命令追加、文件写入、文件同步三个步骤。

从持久化中恢复数据

RDB文件的载入工作是在服务器启动时自动执行的,所以Redis并没有专门用于载入RDB文件的命令,只要Redis服务器在启动时检测到RDB文件存在,它就会自动载入RDB文件。

服务器在载入RDB文件期间，会一直处于阻塞状态 ，直到载入完成。

另外值得一提的是,因为AOF文件的更新频率通常比RDB文件的更新频率高, 保存的数据更完整，AOF基本上最多损失1s的数据。所以:

• 如果服务器开启了AOF持久化功能,那么服务器会优先使用AOF文件来还原数据阵状态。
• 只有在AOF持久化功能处于关闭状态时,服务器才会使用RDB文件来还原数据库状态。

每当执行服务器(定时)任务或者函数时flushAppendOnlyFile 函数都会被调用， 这个函数执行以下两个工作
aof写入保存：

WRITE：根据条件，将 aof\_buf 中的缓存写入到 AOF 文件

SAVE：根据条件，调用 fsync 或 fdatasync 函数，将 AOF 文件保存到磁盘中。

那么这里为什么要先写入buf在同步到磁盘呢？如果实时写入磁盘会带来非常高的磁盘IO，影响整体性能。

aof重写是为了减少aof文件的大小，可以手动或者自动触发

手动触发： bgrewriteaof，自动触发 就是根据配置规则来触发，当然自动触发的整体时间还跟Redis的定时任务频率有关系。

下面来看看重写的一个流程图：

对于上图有四个关键点补充一下：

• 在重写期间，由于主进程依然在响应命令，为了保证最终备份的完整性；因此它依然会写入旧的AOF file中，如果重写失败，能够保证数据不丢失。
• 为了把重写期间响应的写入信息也写入到新的文件中，因此也会为子进程保留一个buf，防止新写的file丢失数据。
• 重写是直接把当前内存的数据生成对应命令，并不需要读取老的AOF文件进行分析、命令合并。
• AOF文件直接采用的文本协议，主要是兼容性好、追加方便、可读性高可认为修改修复。
• 不管是RDB还是AOF都是先写入一个临时文件，然后通过 rename 完成文件的替换工作。

Aof 的配置

appendonly no # 是否打开 aof日志功能
# 文件名称
appendfilename "appendonly.aof"
appendfsync always   # 每1个命令,都立即同步到aof. 安全,速度慢
#appendfsync everysec # 折衷方案,每秒写1次
#appendfsync no      # 写入工作交给操作系统,由操作系统判断缓冲区大小,统一写入到aof. 同步频率低,速度快,
no-appendfsync-on-rewrite  yes: # 正在导出rdb快照的过程中，是否停止同步aof
auto-aof-rewrite-percentage 100 #aof文件大小比起上次重写时的大小,增长率100%时,重写
auto-aof-rewrite-min-size 64mb #aof文件,至少超过64M时,才重写

AOF和RDB比较

• aof文件比rdb更新频率高，优先使用aof还原数据。—— 更加稳定，数据的完整性更好。
• aof比rdb更安全也更大。—— 记录了每一个写操作，但是随着文件越来越大，可能会影响到redis的写性能。
• rdb性能比aof好：恢复大数据集的速度比AOF快，对CPU和内存的影响比较小。更加适用于需要做冷备份或者对数据恢复要求不高的场景，因为它是间隔一段时间进行持久化。如果在这个时间断内发生宕机，那么这些数据就会丢失。
• 如果两个都配了优先加载AOF。
• AOF适用于对数据安全性较高的场景，比如购物车/订单等关键性业务。

定时任务执行的频率可以在配置文件中通过 hz 10 来设置（这个配置表示1s内执行10次，也就是每100ms触发一次定时任务）。该值最大能够设置为：500，但是不建议超过：100，因为值越大说明执行频率越频繁越高，这会带来CPU的更多消耗，从而影响主进程读写性能。
定时任务使用的是Redis自己实现的 TimeEvent，它会定时去调用一些命令完成定时任务，这些任务可能会阻塞主进程导致Redis性能下降。因此我们在配置Redis时，一定要整体考虑一些会触发定时任务的配置，根据实际情况进行调整。

以上就是redis持久化AOF和RDB的区别及解决各个场景问题示例的详细内容，更多关于redis持久化AOF RDB的资料请关注脚本之家其它相关文章！

最新评论