Redis持久化之RDB和AOF

2022-01-13 00:20:02 浏览数 (1)

1 简介

Redis是一个键值对数据库服务器,由于Redis是内存数据库,那么有很多内存的特点,例如掉电易失,或者进程退出,服务器中的数据也将消失不见,所以需要一种方法将数据从内存中写到磁盘,这一过程称之为数据持久化。

持久化有两种方式,一种是RDB,操作手段是将数据从内存中写到磁盘,生成一个经过压缩的RDB文件,另一种持久化方式叫AOF,是把Redis执行的命令行逐句记录下来,追加在类似日志的文件中。

2 RDB持久化

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

SAVE是线程阻塞的,当调用这个命令后,服务器不再对外提供服务,直到内存中需要存储的数据全都持久化为RDB文件。

bgsave与save不同,bgsave会创建一个子线程来完成数据持久化的任务,主服务器依旧对外提供服务。

无论是哪种方式,底层都是调用同一个函数rdb.c/rdbSave()来完成,下面是二者实现的伪代码:

代码语言：javascript复制
def save():
	rdbSave()
  
  
def BGSAVE():
	# 创建子进程
	pid = fork()
        if pid == 0:
			# 子进程创建RDB文件
			rdbSave()
            # 完成之后向父进程发送信号
             signal_parent()
         if pid > 0
             # 父进程继续处理请求,并通过轮询等待子进程的信号
             handle_request_and_wait_signal()
         else:   
			# 处理出错情况
			 handle_fork_error()

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

另外值得一提的是，因为AOF文件的更新频率通常比RDB文件的更新频率高，所以：如果服务器开启了AOF持久化功能，那么服务器会优先使用AOF文件来还原数据库状态。只有在AOF持久化功能处于关闭状态时，服务器才会使用RDB文件来还原数据库状态。

因为BGSAVE命令可以在不阻塞服务器进程的情况下执行，所以Redis允许用户通过设置服务器配置的save选项，让服务器每隔一段时间自动执行一次BGSAVE命令。也可以通过启动Redis服务器时,将这些配置信息保存进对应的.conf

如果持久化配置如下:

代码语言：javascript复制
save 900 1 
save 300 10 
save 60 10000

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

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

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

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

2.1 文件结构

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

databases部分包含着零个或任意多个数据库，以及各个数据库中的键值对数据：如果服务器的数据库状态为空（所有数据库都是空的），那么这个部分也为空，长度为0字节。 ·如果服务器的数据库状态为非空（有至少一个数据库非空），那么这个部分也为非空，根据数据库所保存键值对的数量、类型和内容不同，这个部分的长度也会有所不同。

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

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

3 AOF持久化

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

如果我们对空白的数据库执行以下写命令，那么数据库中将包含三个键值对:

代码语言：javascript复制
redis> SET msg "hello" OK redis> SADD fruits "apple" "banana" "cherry" (integer) 3 redis> RPUSH numbers 128 256 512 (integer) 3

RDB持久化保存数据库状态的方法是将msg、fruits、numbers三个键的键值对保存到RDB文件中，而AOF持久化保存数据库状态的方法则是将服务器执行的SET、SADD、RPUSH三个命令保存到AOF文件中。 被写入AOF文件的所有命令都是以Redis的命令请求协议格式保存的，因为Redis的命令请求协议是纯文本格式，所以我们可以直接打开一个AOF文件，观察里面的内容。 例如，对于之前执行的三个写命令来说，服务器将产生包含以下内容的AOF文件：

代码语言：javascript复制
*2rn$6rnSELECTrn$1rn0rn *3rn$3rnSETrn$3rnmsgrn$5rnhellorn *5rn$4rnSADDrn$6rnfruitsrn$5rnapplern$6rnbananarn$6rncherryrn *5rn$5rnRPUSHrn$7rnnumbersrn$3rn128rn$3rn256rn$3rn512rn

在这个AOF文件里面，除了用于指定数据库的SELECT命令是服务器自动添加的之外，其他都是我们之前通过客户端发送的命令。 服务器在启动时，可以通过载入和执行AOF文件中保存的命令来还原服务器关闭之前的数据库状态，以下就是服务器载入AOF文件并还原数据库状态时打印的日志:

代码语言：javascript复制
[8321] 05 Sep 11:58:50.448 # Server started, Redisversion 2.9.11
[8321] 05 Sep 11:58:50.449 * DB loaded from append only file: 0.000 seconds
[8321] 05 Sep 11:58:50.449 * The server is now ready to accept connections on port 6379

3.1 AOF持久化流程

AOF持久化功能的实现可以分为命令追加（append）、文件写入、文件同步（sync）三个步骤;

命令追加

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

文件的写入与同步

Redis的服务器进程就是一个事件循环（loop），这个循环中的文件事件负责接收客户端的命令请求，以及向客户端发送命令回复，而时间事件则负责执行像serverCron函数这样需要定时运行的函数。

因为服务器在处理文件事件时可能会执行写命令，使得一些内容被追加到aof_buf缓冲区里面，所以在服务器每次结束一个事件循环之前，它都会调用flushAppendOnlyFile函数，考虑是否需要将aof_buf缓冲区中的内容写入和保存到AOF文件里面，这个过程可以用以下伪代码表示：

代码语言：javascript复制
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 文件的时间距离现在超过一秒钟， 那么再次对 AOF 文件进行同步， 并且这个同步操作是由一个线程专门负责执行的。

no

将 aof_buf 缓冲区中的所有内容写入到 AOF 文件， 但并不对 AOF 文件进行同步， 何时同步由操作系统来决定。

如果用户没有主动为appendfsync选项设置值，那么appendfsync选项的默认值为everysec;

3.2 AOF存在问题

为了提高文件的写入效率， 在现代操作系统中， 当用户调用 write 函数， 将一些数据写入到文件的时候， 操作系统通常会将写入数据暂时保存在一个内存缓冲区里面， 等到缓冲区的空间被填满、或者超过了指定的时限之后， 才真正地将缓冲区中的数据写入到磁盘里面。

这种做法虽然提高了效率， 但也为写入数据带来了安全问题， 因为如果计算机发生停机， 那么保存在内存缓冲区里面的写入数据将会丢失。

为此， 系统提供了 fsync 和 fdatasync 两个同步函数， 它们可以强制让操作系统立即将缓冲区中的数据写入到硬盘里面， 从而确保写入数据的安全性。

3.3 AOF持久化的效率和安全性

服务器配置 appendfsync 选项的值直接决定 AOF 持久化功能的效率和安全性。

当 appendfsync 的值为 always 时， 服务器在每个事件循环都要将 aof_buf 缓冲区中的所有内容写入到 AOF 文件， 并且同步 AOF 文件， 所以 always 的效率是 appendfsync 选项三个值当中最慢的一个， 但从安全性来说， always 也是最安全的， 因为即使出现故障停机， AOF 持久化也只会丢失一个事件循环中所产生的命令数据。

当 appendfsync 的值为 everysec 时， 服务器在每个事件循环都要将 aof_buf 缓冲区中的所有内容写入到 AOF 文件， 并且每隔超过一秒就要在子线程中对 AOF 文件进行一次同步： 从效率上来讲， everysec 模式足够快， 并且就算出现故障停机， 数据库也只丢失一秒钟的命令数据。

当 appendfsync 的值为 no 时， 服务器在每个事件循环都要将 aof_buf 缓冲区中的所有内容写入到 AOF 文件， 至于何时对 AOF 文件进行同步， 则由操作系统控制。

因为处于 no 模式下的 flushAppendOnlyFile 调用无须执行同步操作， 所以该模式下的 AOF 文件写入速度总是最快的， 不过因为这种模式会在系统缓存中积累一段时间的写入数据， 所以该模式的单次同步时长通常是三种模式中时间最长的： 从平摊操作的角度来看， no 模式和 everysec 模式的效率类似， 当出现故障停机时， 使用 no 模式的服务器将丢失上次同步 AOF 文件之后的所有写命令数据。

3.4 AOF重写

AOF持久化是通过保存被执行的写命令来记录数据库状态的，所以随着服务器运行时间的流逝，AOF文件中的内容会越来越多，文件的体积也会越来越大，如果不加以控制的话，体积过大的AOF文件很可能对Redis服务器、甚至整个宿主计算机造成影响，并且AOF文件的体积越大，使用AOF文件来进行数据还原所需的时间就越多。

为了解决AOF文件体积膨胀的问题，Redis提供了AOF文件重写（rewrite）功能。通过该功能，Redis服务器可以创建一个新的AOF文件来替代现有的AOF文件，新旧两个AOF文件所保存的数据库状态相同，但新AOF文件不会包含任何浪费空间的冗余命令，所以新AOF文件的体积通常会比旧AOF文件的体积要小得多。

虽然Redis将生成新AOF文件替换旧AOF文件的功能命名为“AOF文件重写”，但实际上，AOF文件重写并不需要对现有的AOF文件进行任何读取、分析或者写入操作，这个功能是通过读取服务器当前的数据库状态来实现的。

在实际中，为了避免在执行命令时造成客户端输入缓冲区溢出，重写程序在处理列表、哈希表、集合、有序集合这四种可能会带有多个元素的键时，会先检查键所包含的元素数量，如果元素的数量超过了redis.h/REDIS_AOF_REWRITE_ITEMS_PER_CMD常量的值，那么重写程序将使用多条命令来记录键的值，而不单单使用一条命令。重写可以交给子线程。

云数据库Redis®

0 人点赞