Redis

关注公众号 jb51net

关闭
首页 > 数据库 > Redis > redis持久化AOF RDB

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

作者:jacheut

这篇文章主要为大家介绍了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 基本不会被使用到,我们重点看看 bgsave 这个命令是如何完成RDB的持久化的。

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

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

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

其次,在BGSAVE命令执行期间,客户端发送的BGSAVE命令会被服务器拒绝,因为同时执行两个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的数据。所以:

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

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

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

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

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

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

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

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

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

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

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

您可能感兴趣的文章:
阅读全文