目的

为了方便起见，将服务器中的非空数据库以及它们的键值对统称为数据库状态。

为了解决服务器进程退出，数据库状态也会消失不见的问题，Redis提供了RDB持久化功能，这个功能可以将Redis在内存中的数据库状态保存到磁盘里面，避免数据意外丢失。

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

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

RDB文件的创建与载入

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

  • SAVE：阻塞Redis服务器进程，直到RDB文件创建完毕为止。
  • BGSAVE：派生出一个子进程，由子进程负责创建RDB文件，服务器进程（父进程）继续处理命令请求。

创建RDB文件的实际工作由rdb.c/rdbSave函数完成，SAVE命令和BGSAVE命令会以不同的方式调用这个函数，两个方法的区别如下伪代码所示：

def save():
    rdbSave()

def bgsave():
    # 创建子进程
    pid = fork()
    if pid == 0:
        # 子进程创建RDB文件
        rdbSave()
        # 完成后向父进程发送信号
        signal_parent()
    elif pid > 0:
        # 父进程继续处理请求命令
        handle_request_and _write()
    else:
        # 处理出错情况
        handle_fork_error()

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

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

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

载入RDB文件的实际工作由rdb.c/rdbLoad函数完成。

在BGSAVE命令执行期间，服务器处理SAVE、BGSAVE、BGREWRITEAOF三个命令的方式和平时有所不同。

  1. BGSAVE命令执行期间，SAVE命令会被服务器拒绝，防止产生竞争条件。
  2. BGSAVE命令执行期间，BGSAVE命令会被服务器拒绝，防止产生竞争条件。

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

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

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

自动间隔性保存

因为BGSAVE命令可以在不阻塞服务器进程的情况下执行，所以Redis允许用户通过设置服务器配置的save选项，让服务器每隔一段时间自动执行一次BGSAVE命令。

用户可以通过save选项设置多个保存条件，但只要其中任意一个条件被满足，服务器就会执行BGSAVE命令。

默认配置：

save 900 1
save 300 10
save 60 10000

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

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

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

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

设置保存条件

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

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

struct redisServer{
	//记录保存条件的数组
    struct saveparam *saveparams;
};
"""
saveparams属性是一个数组，数组中的每个元素都是一个saveparam结构，
每个saveparam结构都保存了一个save选项设置的保存条件
"""
struct saveparam {
	//秒数
    time_t seconds;
    //修改数
    int changes;
};

dirty计数器和lastsave属性

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

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

检查保存条件是否满足

Redis的服务器周期性操作函数serverCron默认每隔100毫秒就会执行一次，该函数用于对正在运行的服务器进行维护，它的其中一项工作就是检查save选项所设置的保存条件是否已经满足，如果满足的话，就执行BGSAVE命令。

img

程序会遍历并检查saveparams数组中的所有保存条件，只要有任意一个条件被满足，那么服务器就会执行BGSAVE命令。

以上就是Redis服务器根据save选项所设置的保存条件，自动执行BGSAVE命令，进行间隔性数据保存的实现原理。

RDB文件结构

一个完整RDB文件所包含的各个部分如下

REDIS db_version databases EOF check_sum

全大写单词标示常量，全小写单词标示变量和数据。

RDB文件的最开头是REDIS部分，这个部分的长度为5字节，保存着“REDIS”五个字符。通过这五个字符，程序可以在载入文件时，快速检查所载入的文件是否RDB文件。

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

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

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

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

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

databases部分

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

例如，如果服务器的0号数据库和3号数据库非空，那么服务器创建一个如下表所示的RDB文件：

REDIS db_version databases0 databases3 EOF check_sum

每个非空数据库在RDB文件中都可以保存为SELECTDB、db_number、key_value_pairs三个部分。

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

db_number保存着一个数据库号码。当程序读取db_number之后，服务器会调用SELECT命令，根据读入的数据库号码进行数据库切换。

key_value_pairs部分保存了数据库中的所有键值对数据，如果键值对带有过期时间，那么过期时间也会和键值对保存在一起。

例如，一个完整的RDB文件，文件中包含了0号数据库和3号数据库：

REDIS db_version SELECTDB 0 pairs SELECTDB 3 pairs EOF check_sum

key_value_pairs部分

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

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

  • REDIS_RDB_TYPE_STRING

  • REDIS_RDB_TYPE_LIST

  • REDIS_RDB_TYPE_SET

  • REDIS_RDB_TYPE_ZSET

  • REDIS_RDB_TYPE_HASH

  • REDIS_RDB_TYPE_LIST_ZIPLIST

  • REDIS_RDB_TYPE_SET_INTSET

  • REDIS_RDB_TYPE_ZSET_ZIPLIST

  • REDIS_RDB_TYPE_HASH_ZIPLIST

当服务器读入RDB文件中的键值对数据时，程序会根据TYPE的值来决定如何读入和解释value的数据。key和value分别保存了键值对的键对象和值对象：

  • 其中key总是一个字符串对象，它的编码方式和REDIS_RDB_TYPE_STRING类型的value一样。根据内容长度的不同，key的长度也会有所不同。
  • 根据TYPE类型的不同，以及保存内容长度的不同，保存value的结构和长度也会有所不同，本节稍后会详细说明每种TYPE类型的value结构保存方式。

带有过期时间的键值对新增了EXPIRETIME_MS和ms，它们的意义如下：

  • EXPIRETIME_MS常量的长度为1字节，以毫秒为单位。
  • ms是一个8字节长的带符号整数，记录着一个以毫秒为单位的UNIX时间戳，这个时间戳就是键值对的过期时间。

value的编码

RDB文件中的每个value部分都保存了一个值对象，每个值对象的类型都由与之对应的TYPE记录。

字符串对象

TYPE = REDIS_RDB_TYPE_STRING时，value保存的是一个字符串对象，字符串对象的编码可以是REDIS_ENCODING_INT或者REDIS_ENCODING_RAW。

如果字符串对象的编码为REDIS_ENCODING_INT，那么说明对象中保存的是长度不超过32位的整数。

ENCODING integer

其中，ENCODING的值可以是REDIS_RDB_ENC_INT8、REDIS_RDB_ENC_INT16或者REDIS_RDB_ENC_INT32。

如果字符串对象的编码为REDIS_ENCODING_RAW，那么说明对象所保存的是一个字符串值，根据字符串长度的不同，有压缩和不压缩两种方法来保存这个字符串：

  • 如果字符串的长度小于等于20字节，那么这个字符串会直接被原样保存。
  • 如果字符串的长度大于20字节，那么这个字符串会被压缩之后再保存。

如果服务器关闭了RDB文件压缩功能，那么RDB程序总以无压缩的方式保存字符串值。具体信息可以参考redis.conf文件中关于rdbcompression选项的说明。

没有被压缩的字符串，结构如下：

len string

string部分保存了字符串值本身，而len保存了字符串值的长度。

压缩后的字符串，结构如下：

REDIS_RDB_ENC_LZF compressed_len origin_len compressed_string

REDIS_RDB_ENC_LZF常量: 字符串被LZF算法压缩，读入程序在碰到这个常量时，会根据之后的compressed_len、origin_len和compressed_string三部分，对字符串进行解压缩：

  • compressed_len记录字符串被压缩之后的长度。

  • origin_len记录字符串原来的长度。

  • compressed_string记录被压缩之后的字符串。

列表对象

TYPE = REDIS_RDB_TYPE_LIST，value保存的是一个REDIS_ENCODING_LINKEDLIST编码的列表对象，结构如下：

list_length item1 item2 … itemN

list_length记录了列表的长度，它记录列表保存了多少个项（item），读入程序可以通过这个长度知道自己应该读入多少个列表项。

item:： length string

示例：

5 “world”

集合对象

TYPE = REDIS_RDB_TYPE_SET，value保存的是一个REDIS_ENCODING_HT编码的集合对象，结构如下：

set_size elem1 … elemN

set_size是集合的大小，它记录集合保存了多少个元素，读入程序可以通过这个大小知道自己应该读入多少个集合元素。

哈希表对象

TYPE = REDIS_RDB_TYPE_HASH，value保存的是一个REDIS_ENCODING_HT编码的集合对象，结构如下：

hash_size k_v_pair1 k_v_pair2 … k_v_pairN
  • hash_size记录了哈希表的大小，也即是这个哈希表保存了多少键值对，读入程序可以通过这个大小知道自己应该读入多少个键值对。
  • 以key_value_pair开头的部分代表哈希表中的键值对，键值对的键和值都是字符串对象，所以程序会以处理字符串对象的方式来保存和读入键值对。

结构中的每个键值对都以键紧挨着值的方式排列在一起，如下所示：

k1 v1 k2 v2 …

示例，下表展示了一个包含两个键值对的哈希表。

2 1 “a” 5 “apple” 1 “b” 6 “banana”

第一个数字2记录了哈希表的键值对数量，之后跟着的是两个键值对：

  • 第一个键值对的键是长度为1的字符串”a”，值是长度为5的字符串”apple”。
  • 第二个键值对的键是长度为1的字符串”b”，值是长度为6的字符串”banana”。
有序集合对象

TYPE = REDIS_RDB_TYPE_ZSET，value保存的是一个REDIS_ENCODING_SKIPLIST编码的有序集合对象，结构如下：

sorted_set_size elem1 … elemN

sorted_set_size记录了有序集合的大小，读入程序需要根据这个值来决定应该读入多少有序集合元素。

以element开头的部分代表有序集合中的元素，每个元素又分为成员（member）和分值（score）两部分，成员是一个字符串对象，分值则是一个double类型的浮点数，程序在保存RDB文件时会先将分值转换成字符串对象，然后再用保存字符串对象的方法将分值保存起来。

INTSET编码的集合

TYPE = REDIS_RDB_TYPE_SET_INTSET，value保存的是一个整数集合对象，RDB文件保存这种对象的方法是，先将整数集合转换为字符串对象，然后将这个字符串对象保存到RDB文件里面。

如果程序在读入RDB文件的过程中，碰到由整数集合对象转换成的字符串对象，那么程序会根据TYPE值的指示，先读入字符串对象，再将这个字符串对象转换成原来的整数集合对象。

ZIPLIST编码的列表、哈希表或者有序集合

TYPE = REDIS_RDB_TYPE_LIST_ZIPLIST、REDIS_RDB_TYPE_HASH_ZIPLIST或者REDIS_RDB_TYPE_ZSET_ZIPLIST，value保存的是一个压缩列表对象，RDB文件保存这种对象的方法是：

  1. 将压缩列表转换成一个字符串对象。
  2. 将转换所得的字符串对象保存到RDB文件。

如果程序在读入RDB文件的过程中，碰到由压缩列表对象转换成的字符串对象，那么程序会根据TYPE值的指示，执行以下操作：

  1. 读入字符串对象，并将它转换成原来的压缩列表对象。
  2. 根据TYPE，设置压缩列表对象的类型：如果TYPE=REDIS_RDB_TYPE_LIST_ZIPLIST，那么压缩列表对象的类型为列表；如果TYPE=REDIS_RDB_TYPE_HASH_ZIPLIST，那么压缩列表对象的类型为哈希表；如果TYPE=REDIS_RDB_TYPE_ZSET_ZIPLIST，那么压缩列表对象的类型为有序集合。

由于TYPE的存在，即使列表、哈希表和有序集合三种类型都使用压缩列表来保存，RDB读入程序也总可以将读入并转换之后得出的压缩列表设置成原来的类型。

重点回顾

  • RDB文件用于保存和还原Redis服务器所有数据库中的所有键值对数据。

  • SAVE命令由服务器进程直接执行保存操作，所以该命令会阻塞服务器。

  • BGSAVE令由子进程执行保存操作，所以该命令不会阻塞服务器。

  • 服务器状态中会保存所有用save选项设置的保存条件，当任意一个保存条件被满足时，服务器会自动执行BGSAVE命令。

  • RDB文件是一个经过压缩的二进制文件，由多个部分组成。

  • 对于不同类型的键值对，RDB文件会使用不同的方式来保存它们。