1，前言

Redis是内存数据库，数据库状态存储在内存中，为了进行数据持久化，需要将这些数据保存在磁盘中。因此Redis提供了RDB持久化功能。

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

在这里插入图片描述

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

2，RDB持久化

2.1，RDB文件的创建与载入

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

两者的区别在于：

SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完毕，在阻塞期间，服务器不能处理任何命令请求
BGSAVE命令会派生出一个子进程，由子进程负责创建RDB文件，服务器进程（父进程）继续处理请求

SAVE和BGSAVE命令如下：

def SAVE():
	# 创建RDB文件
	rdbSave()

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

SAVE和BGSAVE命令是负责创建RDB文件的，至于载入RDB文件，Redis并没有提供命令，只要Redis服务器在启动时检测到RDB文件存在，就会自动载入

值得一提的是，由于AOF文件的更新频率会比RDB文件的更新频率高（越高代表着数据丢失的越少），所以：

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

在这里插入图片描述

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

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

执行BGSAVE时，客户端发送的SAVE命令会被拒绝，是因为避免父进程（服务器进程）和子进程同时执行两个rdbSave()，为了防止产生竞争条件
在BGSAVE命令期间，客户端发送的BGSAVE命令会被服务器拒绝，因为同时执行两个BGSAVE命令也会产生竞争条件
BGREWRITEAOF和BGSAVE两个命令不能同时执行：
- 如果BGSAVE正在执行，那么客户端发送的BGREWRITEAOF命令会被延迟到BGSAVE执行完毕后执行
- 如果BGREWRITEAOF正在执行，那么客户端发送的BGSAVE命令会被服务器拒绝

因为BGREWIRTEAOF和BGSAVE两个命令的执行实际工作都由子进程执行，所以这两个命令在操作方面并没有什么冲突的地方，之所以不允许同时执行只是一个性能方面的考虑

2.2，自动间隔性保存

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

例如向服务器提供以下配置：

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

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

struct redisServer{
    //...
    
    //记录了保存条件的数组
    struct saveparams *saveparams;
    
    //...
    
    //修改计数器
    long long dirty;
    
    //上一次执行保存的时间
    time_t lastsave;
    
    //...
}

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

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

那么redisServer是怎么保存上面的save设置的条件？

在这里插入图片描述

dirty计数器和lastsave属性

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

dirty计数器记录了距离上一次成功执行SAVE命令或者BGSAVE命令之后，服务器对数据库进行了多少次修改（增删改）
lastsave属性是一个UNIX时间戳，记录了服务器上一次成功执行SAVE命令或者BGSAVE命令的时间

假设有这么一个服务器状态：

在这里插入图片描述

dirty为123表示服务器在上次保存之后，对数据库状态执行了123次修改
lastsave属性则记录了服务器上次执行保存操作的时间为：1378270800（也就是：2013年9月4日零时）

检查保存条件是否满足

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

def serverCron():
	#...

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