Redis的RDB持久化的底层原理

一、介绍

         Redis是一个键值对数据库服务器，服务器中通常包含着任意个非空数据库，而每个非空数据库中又可以包含任意个键值对，为了方便起见，我们将服务器中的非空数据库以及它们的键值对统称为数据库状态。

        举个例子，下图展示了一个包含三个非空数据库的Redis服务器，这三个数据库以及数据库中的键值对就是该服务器的数据库状态。

 

 

         因为Redis是内存数据库，它将自己的数据库状态储存在内存里面，所以如果不想办法将储存在内存中的数据库状态保存到磁盘里面，那么一旦服务器进程退出，服务器中的数据库状态也会消失不见。为了解决这个问题，Redis提供了RDB持久化功能，这个功能可以将Redis在内存中的数据库状态保存到磁盘里面，避免数据意外丢失。

         RDB持久化既可以手动执行，也可以根据服务器配置选项定期执行，该功能可以将某个时间点上的数据库状态保存到一个RDB文件中，如下图所示。

 

          RDB持久化功能所生成的RDB文件是一个经过压缩的二进制文件，通过该文件可以还原生成RDB文件时的数据库状态，如下图所示。

          因为RDB文件是保存在硬盘里面的，所以即使Redis服务器进程退出，甚至运行Redis服务器的计算机停机，但只要RDB文件仍然存在，Redis服务器就可以用它来还原数据库状态。

二、RDB文件的创建与载入

          有两个Redis命令可以用于生成RDB文件，一个是SAVE，另一个是BGSAVE。

          SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求：

redis> SAVE //
等待直到RDB文件创建完毕
OK

          和SAVE命令直接阻塞服务器进程的做法不同，BGSAVE命令会派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程（父进程）继续处理命令请求：

redis> BGSAVE //
派生子进程，并由子进程创建RDB文件
Background saving started

          创建RDB文件的实际工作由rdb.c/rdbSave函数完成，SAVE命令和BGSAVE命令会以不同的方式调用这个函数，通过以下伪代码可以明显地看出这两个命令之间的区别：

def SAVE(): 
# 创建RDB文件 
    rdbSave()
def BGSAVE(): 
# 创建子进程 
     pid = fork() 
     if pid == 0: 
# 子进程负责创建RDB文件 
     rdbSave() 
# 完成之后向父进程发送信号 
     signal_parent() 
     elif pid > 0: 
# 父进程继续处理命令请求，并通过轮询等待子进程的信号 handle_request_and_wait_signal() 
else: 
# 处理出错情况 
handle_fork_error()

          和使用SAVE命令或者BGSAVE命令创建RDB文件不同，RDB文件的载入工作是在服务器启动时自动执行的，所以Redis并没有专门用于载入RDB文件的命令，只要Redis服务器在启动时检测到RDB文件存在，它就会自动载入RDB文件。

          以下是Redis服务器启动时打印的日志记录，其中第二条日志DBloaded from disk:...就是服务器在成功载入RDB文件之后打印的：

$ redis-server
[7379] 30 Aug 21:07:01.270 # Server started, Redis version 2.9.11
[7379] 30 Aug 21:07:01.289 * DB loaded from disk: 0.018 seconds
[7379] 30 Aug 21:07:01.289 * The server is now ready to accept con

          另外值得一提的是，因为AOF文件的更新频率通常比RDB文件的更新频率高，所以：

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

          服务器判断该用哪个文件来还原数据库状态的流程如图所示。

         载入RDB文件的实际工作由rdb.c/rdbLoad函数完成，这个函数和rdbSave函数之间的关系可以用下图表示。

 

       SAVE命令执行时的服务器状态：

       当SAVE命令执行时，Redis服务器会被阻塞，所以当SAVE命令正在执行时，客户端发送的所有命令请求都会被拒绝。只有在服务器执行完SAVE命令、重新开始接受命令请求之后，客户端发送的命令才会被处理。

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

        因为BGSAVE命令的保存工作是由子进程执行的，所以在子进程创建RDB文件的过程中，Redis服务器仍然可以继续处理客户端的命令请求，但是，在BGSAVE命令执行期间，服务器处理SAVE、BGSAVE、BGREWRITEAOF三个命令的方式会和平时有所不同。

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

        最后，BGREWRITEAOF和BGSAVE两个命令不能同时执行：

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

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

       RDB文件载入时的服务器状态：

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

三、自动间隔性保存

        因为BGSAVE命令可以在不阻塞服务器进程的情况下执行，所以Redis允许用户通过设置服务器配置的save选项，让服务器每隔一段时间自动执行一次BGSAVE命令。用户可以通过save选项设置多个保存条件，但只要其中任意一个条件被满足，服务器就会执行BGSAVE命令。

        举个例子，如果我们向服务器提供以下配置： 

save 900 1
save 300 10
save 60 10000

        那么只要满足以下三个条件中的任意一个，BGSAVE命令就会被执行：

  • 服务器在900秒之内，对数据库进行了至少1次修改。
  • 服务器在300秒之内，对数据库进行了至少10次修改。
  • 服务器在60秒之内，对数据库进行了至少10000次修改。

        举个例子，以下是Redis服务器在60秒之内，对数据库进行了至少10000次修改之后，服务器自动执行BGSAVE命令时打印出来的日志：

[5085] 03 Sep 17:09:49.463 * 10000 changes in 60 seconds. Saving...
[5085] 03 Sep 17:09:49.463 * Background saving started by pid 5189
[5189] 03 Sep 17:09:49.522 * DB saved on disk
[5189] 03 Sep 17:09:49.522 * RDB: 0 MB of memory used by copy-on-write
[5085] 03 Sep 17:09:49.563 * Background saving terminated with suc

        设置保存条件：

         当Redis服务器启动时，用户可以通过指定配置文件或者传入启动参数的方式设置save选项，如果用户没有主动设置save选项，那么服务器会为save选项设置默认条件：

save 900 1
save 300 10
save 60 10000

         接着，服务器程序会根据save选项所设置的保存条件，设置服务器状态redisServer结构的saveparams属性：

struct redisServer {
// ...
//
记录了保存条件的数组
struct saveparam *saveparams;
// ...
};

         saveparams属性是一个数组，数组中的每个元素都是一个saveparam 结构，每个saveparam结构都保存了一个save选项设置的保存条件：

struct saveparam {
//
秒数
time_t seconds;
//
修改数
int changes;
};

 

         除了saveparams数组之外，服务器状态还维持着一个dirty计数器， 以及一个lastsave属性：

  • dirty计数器记录距离上一次成功执行SAVE命令或者BGSAVE命令 之后，服务器对数据库状态（服务器中的所有数据库）进行了多少次修 改（包括写入、删除、更新等操作）。
  • lastsave属性是一个UNIX时间戳，记录了服务器上一次成功执行 SAVE命令或者BGSAVE命令的时间。

         当服务器成功执行一个数据库修改命令之后，程序就会对dirty计数 器进行更新：命令修改了多少次数据库，dirty计数器的值就增加多少。

         Redis的服务器周期性操作函数serverCron默认每隔100毫秒就会执 行一次，该函数用于对正在运行的服务器进行维护，它的其中一项工作 就是检查save选项所设置的保存条件是否已经满足，如果满足的话，就 执行BGSAVE命令。比如上图到了lastsave时间的300秒后，dirty被执行了123次，满足了saveparams[2]条件就会自动执行一次BGSAVE命令。dirty就会随着清空，lastsave等于当前时间。

四、RDB文件结构

         为了方便区分变量、数据、常量，文章中用全大写单词标示常 量，用全小写单词标示变量和数据。本章展示的所有RDB文件结构图都 遵循这一规则。 RDB文件的最开头是REDIS部分，这个部分的长度为5字节，保存 着“REDIS”五个字符。通过这五个字符，程序可以在载入文件时，快速 检查所载入的文件是否RDB文件。

         因为RDB文件保存的是二进制数据，而不是C字符串，为了简便起 见，我们用"REDIS"符号代表'R'、'E'、'D'、'I'、'S'五个字符，而不是 带'\0'结尾符号的C字符串'R'、'E'、'D'、'I'、'S'、'\0'。本章介绍的所有内 容，以及展示的所有RDB文件结构图都遵循这一规则。

         db_version长度为4字节，它的值是一个字符串表示的整数，这个整 数记录了RDB文件的版本号，比如"0006"就代表RDB文件的版本为第六 版。本章只介绍第六版RDB文件的结构。

         databases部分包含着零个或任意多个数据库，以及各个数据库中的 键值对数据：

  • 如果服务器的数据库状态为空（所有数据库都是空的），那么这 个部分也为空，长度为0字节。
  • 如果服务器的数据库状态为非空（有至少一个数据库非空），那 么这个部分也为非空，根据数据库所保存键值对的数量、类型和内容不 同，这个部分的长度也会有所不同。

         EOF常量的长度为1字节，这个常量标志着RDB文件正文内容的结 束，当读入程序遇到这个值的时候，它知道所有数据库的所有键值对都 已经载入完毕了。

        check_sum是一个8字节长的无符号整数，保存着一个校验和，这个校验和是程序通过对REDIS、db_version、databases、EOF四个部分的内 容进行计算得出的。服务器在载入RDB文件时，会将载入数据所计算出 的校验和与check_sum所记录的校验和进行对比，以此来检查RDB文件 是否有出错或者损坏的情况出现。

         作为例子，下图展示了一个databases部分为空的RDB文件：文 件开头的"REDIS"表示这是一个RDB文件，之后的"0006"表示这是第六 版的RDB文件，因为databases为空，所以版本号之后直接跟着EOF常 量，最后的6265312314761917404是文件的校验和。

      

         databases部分：

          一个RDB文件的databases部分可以保存任意多个非空数据库。一个RDB文件的databases部分可以保存任意多个非空数据库。

          SELECTDB常量的长度为1字节，当读入程序遇到这个值的时候， 它知道接下来要读入的将是一个数据库号码。

         db_number保存着一个数据库号码，根据号码的大小不同，这个部 分的长度可以是1字节、2字节或者5字节。当程序读入db_number部分之 后，服务器会调用SELECT命令，根据读入的数据库号码进行数据库切 换，使得之后读入的键值对可以载入到正确的数据库中。

         key_value_pairs部分保存了数据库中的所有键值对数据，如果键值 对带有过期时间，那么过期时间也会和键值对保存在一起。根据键值对 的数量、类型、内容以及是否有过期时间等条件的不同， key_value_pairs部分的长度也会有所不同。

一个完整的RDB文件结构

          RDB文件中的每个key_value_pairs部分都保存了一个或以上数量的 键值对，如果键值对带有过期时间的话，那么键值对的过期时间也会被保存在内。不带过期时间的键值对在RDB文件中由TYPE、key、value三部分组成。

         TYPE记录了value的类型，长度为1字节，值可以是以下常量的其中 一个：REDIS_RDB_TYPE_STRING、REDIS_RDB_TYPE_List、REDIS_RDB_TYPE_SET等等

         每个TYPE常量都代表了一种对象类型或者底层编码， 当服务器读入RDB文件中的键值对数据时，程序会根据TYPE的值来决 定如何读入和解释value的数据。key和value分别保存了键值对的键对象和值对象。

         带有过期时间的键值对新增了EXPIRETIME_MS和ms，EXPIRETIME_MS常量的长度为1字节，它告知读入程序，接下 来要读入的将是一个以毫秒为单位的过期时间。EXPIRETIME_MS常量的长度为1字节，它告知读入程序，接下 来要读入的将是一个以毫秒为单位的过期时间。

         RDB文件中的每个value部分都保存了一个值对象，每个值对象的 类型都由与之对应的TYPE记录，根据类型的不同，value部分的结构、 长度也会有所不同。

五、分析RDB文件

         让我们首先从最简单的情况开始，执行以下命令，创建一个数据库 状态为空的RDB文件：

redis> FLUSHALL
OK
redis> SAVE
OK

　　然后调用od命令，打印RDB文件：

$ od -c dump.rdb
0000000 R E D I S 0 0 0 6 377 334 263 C 360 Z 3340000020 362 V
0000022

　　根据之前学习的RDB文件结构知识，当一个RDB文件没有包含任何 数据库数据时，这个RDB文件将由以下四个部分组成：

  • 五个字节的"REDIS"字符串。
  • 四个字节的版本号（db_version）。
  • 一个字节的EOF常量。
  • 八个字节的校验和（check_sum）。

      从od命令的输出中可以看到，最开头的是“REDIS”字符串，之后的 0006是版本号，再之后的一个字节377代表EOF常量，最后的334 263 C 360 Z 334 362 V八个字节则代表RDB文件的校验和。

       因为Redis本身带有RDB文件检查工具redis-check-dump，网上也能 找到很多处理RDB文件的工具，所以人工分析RDB文件的内容并不是学习Redis所必须掌握的技能。

六、重点回顾

  • RDB文件用于保存和还原Redis服务器所有数据库中的所有键值对数据。
  • SAVE命令由服务器进程直接执行保存操作，所以该命令会阻塞服务器。
  • BGSAVE令由子进程执行保存操作，所以该命令不会阻塞服务器。
  • 服务器状态中会保存所有用save选项设置的保存条件，当任意一 个保存条件被满足时，服务器会自动执行BGSAVE命令。
  • RDB文件是一个经过压缩的二进制文件，由多个部分组成。
  • 对于不同类型的键值对，RDB文件会使用不同的方式来保存它们。

简介：

在指定的时间间隔内将数据集快照写入磁盘。

 

持久化过程：

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时RDB文件中，待持久化过程结束，在用这个临时文件替换上次持久化好的文件。整个过程，主进程是不进行如何IO操作的，确保了极高的性能，如果需要大规模数据恢复，且对于数据恢复的完整性不非常敏感，那RDB方式比AOF方式更加高效。RDB的缺点是最后一次持久化的数据可能丢失。

Fork的作用是复制一个与当前进程一样的进程，新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。

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

 

配置：

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

stop-writes-on-bgsave-error yes  当写入数据到硬盘出错,则停止保存到硬盘  推荐yes

rdchecksum yes   # 在存储快照后,可以让redis使用CRC64算法来进行数据校验 # 但是会增加大约10%的性能消耗 # 我觉得10%不算什么

 

优缺点：

优点：可以定期备份，适合大规模数据恢复，容灾性强。节省磁盘空间，主线程不需要进行任何io操作由子进程执行备份。恢复速度快（比AOF快）。

缺点：在持久化期间redis意外宕机会造成最后一次的数据丢失。数据完整性和一致性不高。fork过程中比较耗时，不能达到毫秒级响应。

 

posted @ 2022-03-01 17:15  呆Finn  阅读(191)  评论(0)  编辑  收藏  举报