Redis持久化

Redis持久化

1. RDB持久化

Redis是一个基于内存的键值对数据库，由于Redis是内存数据库，它将自己的数据库状态存储在内存里，所以一旦服务器进程退出，保存在数据库中的数据也将消失。
为了解决这个问题，Redis提供了RDB持久化功能，这个功能将Redis内存中的数据保存在磁盘里，避免数据的丢失。RDB持久化既可以手动执行，也可以根据服务器配置选项定期执行，它可以将某个时间节点内的数据保存到一个RDB文件中。

1.1 RDB文件的创建和载入

有两个Redis命令可以用于生成RDB文件，一个是SAVE，另一个是BGSAVE。
SAVE命令会阻塞Redis服务进程，直到RDB文件创建完成为止，在阻塞期间，服务器不能处理任何命令请求。
BGSAVE命令会派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程继续处理命令请求。

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文件的载入工作是由服务器启动时自动执行的。

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

由于BGSAVE创建RDB文件是由子进程来实现的，Redis服务器仍然可以继续执行客户端的命令请求，但是在BGSAVE命令执行期间，服务器处理SAVE,BGSAVE,BGREWRITEAOF三个命令时会有所不同。

首先，在BGSAVE命令执行期间，客户端发送的SAVE命令或者BGSAVE命令会被服务器拒绝，前者是为了避免父进程和子进程同时执行两个rdbSave调用，产生竞争条件；后者也是为了避免两个BGSAVE命令产生竞争条件。

最后，BGREWRITEAOF和BGSAVE两个命令不能同时执行，这是因为BGREWRITEAOF和BGSAVE两个命令的实际工作都由子进程来执行，所以两个操作并没有什么冲突，不能同时执行是出于一个性能方面的考虑——并发出两个子进程，并且两个子进程同时执行大量的磁盘写入操作，造成服务器性能降低。

1.2 自动间隔保存

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

save 100 1
save 300 10
save 60 10000

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

• 服务器在100秒内，数据库修改过至少一次；
• 服务器在300秒内，数据库修改过至少三次；
• 服务器在60秒内，数据库修改过至少10000次。

设置保存条件

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

save 100 1
save 300 10
save 60 10000

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

struct redisServer {

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

其中，saveparams的结构如下所示：

struct saveparams {

    // 秒数
    time_t seconds;
    
    // 修改数
    int changes;
};

dirty计数器和lastsave属性

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

• dirty计数器记录了距离上一次成功执行SAVE 或者 BGSAVE属性之后，服务器对数据库状态进行了多少次修改；
• lastsave记录了距离上一次执行SAVE命令或者BGSAVE命令的时间。

struct redisServer {
    
    // ...
    
    // saveparams数组
    struct saveparam *saveparams;
    
    // dirty计数器
    long long dirty;
    
    // 上一次保存的时间
    time_t lastsave;
    
    // ...
}；

当服务器成功执行修改数据库的命令时，dirty计数器加一，命令修改了多少次数据库，dirty计数器的值就增加多少。

1.3 检查保存条件是否满足

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()

1.4 RDB文件结构

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

db_version长度为4个字节，它的值是一个字符串表示的整数，这个整数记录了RDB文件版本号。

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

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

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

2. AOF

除了RDB持久化功能之外，Redis还提供了AOF持久化功能，与RDB持久化保存数据库中的键值对来记录数据库状态不同，AOF持久化是通过保存Redis服务器所执行的写命令来记录数据库状态的。

举个例子，我们对空白数据库执行以下命令，那么数据库中包含了2个键值对

RDB持久化保存数据库状态是将msg、number的键值对保存到RDB文件中去，而AOF持久化保存数据库状态的方法则是将服务器执行的set和rpush命令保存到AOF文件中。

1.1 AOF持久化文件的实现

AOF持久化文件的实现可以分为命令追加(append)、文件写入、文件同步三个步骤。

命令追加

当AOF持久化功能处于打开状态时，服务器在执行完一个写命令后，会以协议格式将被执行的写命令追加到服务器状态的aof_buf缓冲区的末尾：

struct redisServer {
    
    // ...
    
    // AOF缓冲区
    sds aof_buf;
    
    // ...
};

当服务器在执行一个set命令后，会将协议内容追加到aof_buf缓冲区的末尾。

AOF文件的写入与同步

Redis服务器进程就是一个时间循环，这个循环中的文件时间负责接受客户端的命令请求，以及向客户端发送命令回复，而时间则负责执行像serverCron函数这样需要定时运行的函数。
因为服务器在处理文件时间时可能会执行写命令，使得一些内容追加到aof_buf缓冲区里，所以在服务器每次结束一个时间循环之前，会调用flushAppendOnlyFile函数，考虑是否将aof_buf缓冲区的内容写入和保存到AOF文件里，这个过程可以用以下代码实现：

def eventLoop() :
    
    while (True):
        
        # 处理文件事件，接受命令请求以及发送命令回复
        # 处理命令请求时可能会有新的命令追加到aof_buf缓冲区
        processFileEvents()
        
        # 处理时间时间
        processTimeEvents()
        
        # 考虑是否将 aof_buf 中的文件内容保存到AOF中
        flushAppendOnlyFile()

flushAppendOnlyFile函数的行为由服务器配置的appendfsync选项的值来决定，各个不同的值产生的行为如表所示：

appendfsync选项的值	flushAppendOnlyFile()函数的行为
always	将aof_buf缓冲区中的所有内容写入并同步到AOF文件中
everysec	将aof_buf缓冲区中的所有内容写入到AOF文件中，如果距离上一次同步AOF文件的时间超过1秒，那么再次对AOF文件进行同步，并且这个同步操作是由一个线程专门负责执行
no	将aof_buf缓冲区中的所有内容写入到AOF文件中，但并不对AOF文件进行同步，何时同步由操作系统决定

appendfsync的默认值为everysec。

Redis 目前支持三种 AOF 保存模式，它们分别是：

• AOF_FSYNC_NO ：不保存。
• AOF_FSYNC_EVERYSEC ：每一秒钟保存一次。
• AOF_FSYNC_ALWAYS ：每执行一个命令保存一次。

1.2 AOF文件的载入与数据还原

Redis读取AOF文件并还原数据库状态的详细步骤如下：

1.3 AOF重写

因为AOF持久化是通过保存被执行的命令来记录数据库状态的，所以随着服务器运行时间的延长，AOF文件的内容会越来越多，文件体积也会越来越大，如果不加以控制，体积过大的AOF文件可能会对Redis服务器造成影响，并且AOF文件体积的增大也会使得数据还原的时间变长。

为了解决这个问题，Redis提供了AOF文件重写功能，通过该功能，Redis可以创建一个新的AOF文件来替换旧的AOF文件，新旧两个AOF文件所保存的数据库状态相同，但是新的AOF文件不会包含任何浪费空间的冗余指令，所以新的AOF文件要比旧的AOF文件小得多。

AOF文件重写的实现

考虑这样一种情况，如果服务器对list键执行了以下命令：

服务器为了保存当前list键的情况，必须在AOF文件中写入这6条命令。
如果服务器想要用尽量少的命令来记录list状态，那么最简单高效的办法是分析并读取当前list的值，然后用一条命令

就可以保存list的值，而不是之前的六条命令。

整个重写的内容可以用以下伪代码来表示：

def aof_rewrite(new_aof_file_name):

	# 创建新的aof文件
	f = create_file(new_aof_file_name)

	# 遍历数据库
	for db in redisServer.db:

		# 忽略空的数据库
		if db.is_empty():continue

		# 写入SELECT命令，指定数据库号码
		f.write_command("SELECT" + db.id)

		# 遍历数据库中的所有键
		for key in db:

			# 忽略已过期的键
			if key.is_expired():continue

			# 根据键的类型对键进行重写
			if key.type = String:
				rewrite_string(key)
			elif key.type = List:
				rewrite_list(key)
			elif key.type = Hash:
				rewrite_hash(key)
			elif key.type = Set:
				rewrite_set(key)
			elif key.type = SortedSet:
				rewrite_sorted_set(key)

			# 如果键带有过期时间，那么过期也要重写
			if key.is_expire_time():
				rewrite_expire_time(key)
	f.close()


def rewrite_string(key):

	# 使用GET命令获取字符串键的值
	value = GET(key)

	# 使用SET命令重写字符串键
	f.write_command(SET, key, value)


def rewrite_list(key):

	# 使用LRANGE命令获取列表键包含的所有键值
	item1, item2, ..., itemN = LRANGE(key, 0, -1)

	f.write_command(RPUSH, key, item1, item2, ... , itemN)

def rewrite_hash(key):

	# 使用HGETALL命令获取所有键值对
	key1, value1, key2, value2, ..., keyN, valueN = HGETALL(key)

	# 使用HSET命令重写哈希键
	f.write_command(HMSET, key, key1, value1, 
		key2, value2, ..., keyN, valueN)

def rewrite_set(key):

	# 使用SMEMBERS 命令获取集合键所有的所有元素
	elem1, elem2, ..., elemN =  SMEMBERS(key)

	f.write_command(SADD, key, elem1, elem2, ..., elemN)

def rewrite_sorted_set(key):

	member1, score1, member2, score2, ... , memberN, scoreN = ZRANGE(
		key, 0, -1)

	f.write_command(ZADD, member1, 
		score1, member2, score2, ... , memberN, scoreN)

def rewrite_expire_time(key):

	# 获取毫秒精度的键过期时间
	timestamp = get_expire_time_in_unixstamp(key)

	# 使用PEXPIREAT命令重写
	f.write_command(PEXPIREAT, key, timestamp)

AOF后台重写

由于AOF重写程序aof_rewrite函数会进行大量的写入工作，所以调用这个函数的线程会被长时间阻塞，如果由服务器调用aof_rewrite函数的话，那么在重写AOF文件期间，服务器将无法处理客户端发送的命令。所以Redis决定将AOF重写程序放入到子进程里来执行，这样做有两个目的：

• 子进程进行AOF重写期间，父进程可以继续执行命令请求；
• 子进程带有服务器进程的数据副本，使用子进程而不是线程，可以避免使用锁的情况下，保证数据的安全性。

但是使用子进程带来的另外一个问题是，服务器当前数据库状态和重写后的AOF文件所保存的数据库状态不一致。如下图所示：

时间	服务器进程	子进程
T1	执行命令 set k1 v1
T2	执行命令 set k2 v2
T3	执行命令 set k3 v3
T4	创建子进程，执行AOF文件重写	开始重写
T5	执行命令 set k2 v2	执行重写操作
T6	执行命令 set k3 v3	执行重写操作
T7	执行命令 set k4 v4	完成重写

为了解决这个问题，Redis设置了一个AOF重写缓冲区，这个服务器在创建子进程后开始使用，当Redis执行完一个写命令后，它同时将这个写命令发送给AOF缓冲区和AOF重写缓冲区。

当子进程完成AOF重写工作之后，它会像父进程发送一个信号，父进程在收到该信号时，会执行信号处理函数，并执行以下工作：

1. 将AOF重写缓冲区中的所有内容写入到新的AOF文件中，此时AOF文件所保存的数据库状态将和服务器当前状态一致；
2. 对新的AOF文件进行改名，原子地覆盖现有的AOF文件，完成新旧两个AOF文件的替换。
   

参考文献

《Redis设计与实现》