RDB持久化

RDB持久化既可以手动执行，也可以根据服务器配置选项定期执行，该功能可以将某一时刻上的数据保存到一个RDB文件中，RDB文件保存在硬盘里，所以即使redis服务器进程退出，甚至运行redis服务器的计算机宕机，只要RDB文件存在，redis服务器就能通过RDB文件还原。

RDB文件的创建和载入

创建

• save命令

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

• bgsave命令

  或派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程(父进程)继续处理命令请求。

创建RDB文件的实际工作是由rdb.c/rdbSave函数完成的。save和bgsave命令会以不同的方式调用这个函数。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// 伪代码理解这两个命令
void save(){
    rdbSave(); //创建RDB文件    
}
void bgsave(){
    pid = fork();//创建子进程
    if(pid == 0)
        rdbSave();//子进程负责创建RDB文件
        signal_parent(); //完成之后向父进程发送信号
    else if (pid > 0)
        //父进程继续处理命令请求，并通过轮询等待子进程的信号
        handle_request_and_wait_signal();
    else
        handle_fork_error();//处理出错情况
}

命令执行时的服务状态：

• save命令：当save命令执行时，redis服务器会阻塞。save命令处理期间，客户端发送的所有命令都会被拒绝；只有在save命令执行结束、重新开始接受命令请求之后，客户端发送的命令才会被处理。

• bgsave命令：由于bgsave命令的保存工作是由子进程执行的，所以子进程在执行创建RDB文件的过程中，redis服务器仍然可以继续处理客户端的命令请求。但是，在bgsave命令执行期间，服务器处理save、bgsave、bgrewriteaof三个命令的方式会有所不同。

  • bgsave执行期间，客户端发送的sava命令会被服务器拒绝，服务器禁止save和bgsave命令同时执行（为了避免父进程和子进程同时执行rdbSave函数，防止产生竞争条件）。

  • bgsave执行期间，客户端发送的bgsava命令会被服务器拒绝，因为同时执行两个bgsave会产生竞争条件。

  • bgsave和bgrewriteaof两个命令不能同时执行

    • 如果basave命令正在执行，客户端发送的bgrewriteaof或被延迟到bgsava执行结束后执行。
    • 如果bgrewriteaof正在执行，客户端发送的bgsave会被服务器拒绝。

    因为bgrewriteaof和bgsave命令的实际工作都是由子线程执行的，所以两个命令在操作方面并没有冲突，不能同时执行是从性能上考虑的(并发出两个子线程，且这两个子线程同时执行大量的磁盘写入操作)。

载入

与创建方式不同，RDB文件的载入工作是在服务器启动时自动执行的，没有设置专门用于载入RDB文件的命令，只要redis服务器在启动时，检测到RDB文件存在，就会自动载入RDB文件。

在启动时打印的日志中：红色框选出来的内容，就是redis服务器成功加载RDB文件之后打印的。

由于AOF文件的更新频率通常比RDB文件的更新频率高，所以：

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

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

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

自动间隔性保存

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

用户可以通过save选项设置多个保存条件，但是其中任意一个条件被满足，服务器就会执行bgsave命令。如下redis服务配置文件中默认的save配置：

1
2
3

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

保存条件

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

1
2
3

save 900 1
save 300 10
save 60 10000

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

1
2
3
4
5
6

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

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

1
2
3
4
5
6

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

例如，上述中默认的配置，就会如下图所示。

dirty计数器和lastsave属性

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

• dirty计数器记录距离上一次成功执行save命令或者bgsave命令之后，服务器对数据进行了多少次写操作(包含写入、删除、更新等)
• lastsave属性是一个unix时间戳，记录了服务器上一次成功执行save命令或bgsave命令的时间。

1
2
3
4
5
6
7
8

struct redisServer {
    // ...
    //修改计数器
    long long dirty;
    //上一次执行保存的时间
    time_t lastsave;
    // ...
};

检查保存条件是否满足

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

void saverCron(){
    // ...
    // 遍历所有保存条件
    server.saveparams.forEach(saveparam->{
        // 计算距离上次执行保存操作有多少秒
        save_interval = unixtime_now()-server.lastsave
        // 如果数据库状态的修改次数超过条件所设置的次数
        ///并且距离上次保存的时间超过条件所设置的时间
        ///那么执行保存操作
        if (server.dirty >= saveparam.changes && 
           save_interval > saveparam.seconds){
            bgsave()            
        }
    })
}

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

示例：

一台redis服务器的当前状态：

那么当时间来到1378271101，也即是1378270800的301秒之后，且数据有10改动，那么服务器将自动执行一次bgsave。假设，bgsave执行了5秒，那么其中的dirty及数据会被重重为0，而lastsave属性或被更新成1378271106。此时服务器的当前状态为：

RDB文件结构

todo