深入学习Redis持久化(RDB)

发布于 2022-4-17 10:49
浏览
0收藏

来源:左耳君(ID:qaqzuoer)

作者: 湿兄

前言

Redis持久化:分为RDB和AOF两种,属于Redis高可用技术之一

在web服务器中,高可用是指服务器可以正常访问的时间,衡量的标准是在多长时间内可以提供正常服务(99.9%、99.99%、99.999% 等等)

我们在这里考虑Redis的高可用可以涉及更多的因素,除了正常的服务(如主从分离、快速容灾技术),还需要考虑数据容量的扩展、数据安全不会丢失等。

在Redis中,我们可以将实现高可用技术划分为:持久化、主从复制、哨兵模式和集群(其实也可以不把持久化划分为高可用技术,这都无所谓)

持久化:持久化最容易理解,主要就是将数据备份,将数据备份到硬盘上,不会因为机器宕机停电等造成数据丢失

主从复制:复制主要实现了多个机器的备份,以及对于读操作的负载均衡和简单的故障恢复(哨兵和集群都是在复制的基础上实现高可用的)存在缺陷:存储能力受到单机限制,写操作无法负载均衡,故障无法自动恢复

哨兵模式:在复制的基础上,哨兵实现了自动化的故障恢复。缺陷:写操作无法负载均衡;存储能力受到单机的限制。

集群:通过集群,Redis解决了写操作无法负载均衡,以及存储能力受到单机限制的问题,实现了较为完善的高可用方案。

Redis持久化概述

持久化指的是将数据永久保存在磁盘中,不会因为机器宕机等导致数据丢失现象

Redis是内存数据库,数据都是存储在内存中的,为了避免进程退出而导致数据丢失,需要定期的将内存中的数据以某种形式(数据或者命令)存储到硬盘中,即使发生情况,下次Redis重启的时候会利用持久化的文件实现数据恢复

为了进行灾难备份,可以将持久化文件拷贝到一个远程位置

最近发生的一个事情,GitHub将你的代码打包送到了北极封存千年,来感受一下~~

只要你2月2日以前贡献过的开源代码,现在都已经被埋在北极的冰雪之下,保存一千年。

想一想你的代码在千年之后,会被后人读到,可能还会感叹先人之伟大(估计会骂两句:这垃圾代码谁写的...),瞬间是不是觉得自己是街上最亮的仔了 

Redis持久化分为RDB持久化和AOF持久化:前者将当前数据保存到硬盘,后者则是将每次执行的写命令保存到硬盘(类似于MySQL的binlog)

由于AOF持久化的实时性更好,即当进程意外退出时丢失的数据更少,因此AOF是目前主流的持久化方式,不过RDB持久化仍然有其用武之地。

RDB持久化

RDB持久化是将当前进程中的数据生成快照保存在硬盘中,也就是持久化,保存的文件后缀是.rdb,当Redis重新启动时,我们可以通过rdb文件来恢复数据

触发条件:

RDB持久化分为手动触发和自动触发两种

1、手动触发

手动触发就是我们用命令去触发RDB持久化,生成持久化文件,我们可以通过save()或者bgsave()命令去生成RDB文件

  • save()命令会阻塞Redis服务器的进程直到RDB文件创建为止,在Redis服务器阻塞期间,服务器不能处理任何请求
  • bgsave()命令会创建一个子进程,由子进程来负责创建RDB文件,父进程则继续处理请求 深入学习Redis持久化(RDB)-开源基础软件社区

bgsave()命令执行过程中,只有fork子进程的时候会阻塞服务器,而对于save()命令整个过程都会阻塞服务器,因此save()已经基本废弃

自动触发RDB时,Redis也是选择bgsave()去执行持久化而不是save,下面介绍自动触发RDB持久化的条件

2、自动触发

自动触发最常见的情况就是在配置文件中来设置了,在配置文件中通过

save m n指定m秒内发生n次变化时,会触发bgsave()

我们可以打开redis安装目录的配置文件:深入学习Redis持久化(RDB)-开源基础软件社区

save 900 1的意思是:当时间到900秒时,如果redis数据发生了至少1次变化,则执行bgsave;save 300 10和save 60 10000同理。当三个save条件满足任意一个时,都会引起bgsave的调用

实现原理:通过serverCron函数、dirty计数器和laststave时间戳来实现

每隔100ms,执行serverCron函数;在serverCron函数中,遍历save m n配置的保存条件,只要有一个条件满足,就进行bgsave。对于每一个save m n条件,只有下面两条同时满足时才算满足:

  • 当前时间-lastsave > m
  • dirty >= n

3、其它自动触发

除了上面说的两种情况,还有一些其它情况会触发bgsave()函数其实

执行shutdown命令,会自动执行RDB持久化

在主从复制场景下,如果从节点执行全量复制,则主节点会执行bgsave操作并将rdb文件发送给从节点

全量复制和部分复制问题,会在主从复制篇讲解

bgsave()执行流程:深入学习Redis持久化(RDB)-开源基础软件社区

可以大致分为5个步骤:

  1. Redis父进程判断当前是否在执行save、bgsave或者bgrewriteaof的子进程,如果在执行直接返回。bgsave和bgrewriteaof的子进程不能同时执行,个人认为主要是基于性能考虑,两个大量磁盘写操作的进程执行可能会引发严重的性能问题
  2. 父进程fork创建子进程,fork过程父进程是阻塞的,Redis不能执行来自客户端的任何命令
  3. 父进程fork之后,bgsave命令返回”Background saving started”信息并不再阻塞父进程,并可以响应其他命令
  4. 子进程创建RDB文件,根据父进程内存快照生成临时快照文件,完成后对原有文件进行原子替换
  5. 子进程发送信号给父进程表示完成,父进程更新统计信息

RDB文件

RDB文件是经过压缩的二进制文件,接下来我们看一些其中的细节

存储路径:

RDB文件的存储路径既可以在启动前配置,也可以通过命令动态设定

直接配置:dir配置指定目录,dbfilename指定文件名。默认是Redis根目录下的dump.rdb文件

动态设置:Redis启动后也可以动态修改RDB存储路径,在磁盘损害或空间不足时非常有用,执行命令为config set dir {newdir}和config set dbfilename {newFileName}RDB文件格式: 深入学习Redis持久化(RDB)-开源基础软件社区

简单了解下各个字段的含义:

  • REDIS:常量,保存着”REDIS”5个字符。
  • db_version:RDB文件的版本号,注意不是Redis的版本号。
  • SELECTDB 0 pairs:表示一个完整的数据库(0号数据库)
  • EOF:常量,标志RDB文件正文内容结束
  • check_sum:前面所有内容的校验和;Redis在载入RBD文件时,会计算前面的校验和并与check_sum值比较,判断文件是否损坏

压缩:

Redis默认采用LZF算法对RDB文件进行压缩。虽然压缩耗时,但是可以大大减小RDB文件的体积,因此压缩默认开启;可以通过命令关闭:深入学习Redis持久化(RDB)-开源基础软件社区

需要注意的是,RDB文件的压缩并不是针对整个文件进行的,而是对数据库中的字符串进行的,且只有在字符串达到一定长度(20字节)时才会进行

启动时加载:

RDB文件的载入工作是在服务器启动时自动执行的,并没有专门的命令。但是由于AOF的优先级更高,因此当AOF开启时,Redis会优先载入AOF文件来恢复数据;只有当AOF关闭时,才会在Redis服务器启动时检测RDB文件,并自动载入。服务器载入RDB文件期间处于阻塞状态,直到载入完成为止

Redis载入RDB文件时,会对RDB文件进行校验,如果文件损坏,则日志中会打印错误,Redis启动失败。

RDB常用配置总结:

下面是RDB常用的配置项,以及默认值;前面介绍过的这里不再详细介绍

1、save m n:bgsave自动触发的条件;如果没有save m n配置,相当于自动的RDB持久化关闭,不过此时仍可以通过其他方式触发

2、stop-writes-on-bgsave-error yes:当bgsave出现错误时,Redis是否停止执行写命令;设置为yes,则当硬盘出现问题时,可以及时发现,避免数据的大量丢失;设置为no,则Redis无视bgsave的错误继续执行写命令,当对Redis服务器的系统(尤其是硬盘)使用了监控时,该选项考虑设置为no

3、rdbchecksum yes:是否开启RDB文件的校验,在写入文件和读取文件时都起作用;关闭checksum在写入文件和启动文件时大约能带来10%的性能提升,但是数据损坏时无法发现

4、rdbcompression yes:是否开启RDB文件压缩

5、dbfilename dump.rdb:RDB文件名

6、dir ./:RDB文件和AOF文件所在目录

标签
收藏
回复
举报
回复
添加资源
添加资源将有机会获得更多曝光,你也可以直接关联已上传资源 去关联
    相关推荐