数据库
首页 > 数据库> > Redis-技术专区-帮从底层彻底吃透RDB技术原理

Redis-技术专区-帮从底层彻底吃透RDB技术原理

作者:互联网

每日一句

低头是一种能力,它不是自卑,也不是怯弱,它是清醒中的嬗变。有时,稍微低一下头,或者我们的人生路会更精彩。

前提概要

Redis是一个的键-值(K-V)对的内存数据库服务,通常包含了任意个非空数据库。而每个非空的键值数据库中又可以存放任意个K-V,基本的结构如下图所示:

image

Redis服务器的结构

RDB持久化方式

RDB持久化是指在指定的时间间隔内将redis内存中的数据集快照写入磁盘,实现原理是redis服务在指定的时间间隔内先fork一个子进程,由子进程将数据集写入临时文件,写入成功后,再替换之前的文件,用二进制压缩存储,生成dump.rdb文件存放在磁盘中。

image

RDB机制

RDB优势

RDB劣势

RDB配置规则

在redis的6379.conf配置文件中:

备份配置参数

save <seconds> <changes>

save <指定时间间隔> <执行指定次数更新操作>,满足条件就将内存中的数据同步到硬盘中。官方出厂配置默认是 900秒内有1个更改,300秒内有10个更改以及60秒内有10000个更改,则将内存中的数据快照写入磁盘。

save 900 1      #在900秒(15分钟)之后,如果至少有一个key发生变化,则dump内存快照
save 300 10     #在300秒(15分钟)之后,如果至少有10个key发生变化,则dump内存快照
save 60 10000   #在60秒(1分钟)之后,如果至少有10000个key发生变化,则dump内存快照

文件配置参数

默认的rdb文件路径是当前目录,文件名是dump.rdb,可以在配置文件中修改路径和文件名,分别是dir和dbfilename.

# 存放快照的目录
dir ./ # rdb文件存储路径
dbfilename dump.rdb # rdb文件名

压缩配置参数

在进行镜像备份时,是否进行压缩。

rdbcompression yes  #Redis默认是开启压缩的。
# yes:压缩,但是需要一些cpu的消耗。
# no:不压缩,需要更多的磁盘空间。

如果没有触发自动快照,需要对Redis执行手动快照操作,save和bgsave命令来手动快照,两个命令是:

注意:由于Redis使用fork来复制一份当前进程,那么子进程就会占有和主进程一样的内存资源,比如说主进程8G内存,那么在备份的时候,必须保证有16G的内存,要不然会启用虚拟内存,性能非常的差。

快照的过程如下:

  1. Redis使用fork函数复制一份当前进程(父进程)的副本(子进程);
  2. 父进程继续接收并处理客户端发来的命令,而子进程开始将内存中的数据写入硬盘中的临时文件;
  3. 当子进程写入完所有数据后会用该临时文件替换旧的RDB文件,至此一次快照操作完成。(注意:会存在写一部命令压缩缓存区,记录写入rdb文件时候的操作)

在执行fork的时候操作系统会使用写时复制(copy-on-write)策略,即fork函数发生的一刻父子进程共享同一内存数据,当父进程要更改其中某片数据时(如执行一个写命令),操作系统会将该片数据复制一份以保证子进程的数据不受影响,所以新的RDB文件存储的是执行fork时那一刻的内存快照数据。

通过上述过程可以发现Redis在进行快照的过程中不会修改RDB文件,只有快照结束后才会将旧的文件替换成新的,也就是说任何时候RDB文件都是完整的。这使得可以通过定时备份RDB文件来实现Redis数据库备份。

快照的过程压缩分析:

RDB文件是经过压缩(上文介绍了:可以配置rdbcompression参数以禁用压缩节省CPU占用)的二进制格式,所以占用的空间会小于内存中的数据大小,更加利于传输。

快照的读取加载过程:

RDB 的优缺点

优点:

  1. 适合大规模的数据恢复。
  2. 如果业务对数据完整性和一致性要求不高,RDB是很好的选择。

缺点:

  1. 数据的完整性和一致性不高,因为RDB可能在最后一次备份时宕机了。
  2. 备份时占用内存,因为Redis 在备份时会独立创建一个子进程,将数据写入到一个临时文件(此时内存中的数据是原来的两倍),最后再将临时文件替换之前的备份文件。
  3. 由于RDB是通过fork子进程来协助完成数据持久化工作的,因此,如果当数据集较大时,可能会导致整个服务器停止服务几百毫秒,甚至是1秒钟。(回写和覆盖的时候用的是主进程)。

RDB与AOF二者选择的标准(虽然还没有讲AOF,提前普及)

Redis允许同时开启AOF和RDB,既保证了数据安全又使得进行备份等操作十分容易。此时重新启动Redis后Redis会使用AOF文件来恢复数据,因为AOF方式的持久化可能丢失的数据更少。

总结

所以Redis的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。

标签:吃透,Redis,内存,RDB,进程,快照,数据
来源: https://www.cnblogs.com/liboware/p/15224969.html