Redis|Redis持久化：RDB持久化和AOF持久化

﹏ヽ暗。殇╰゛Y 2021-12-08 18:35 588阅读 0赞

### Redis持久化之RDB持久化 ###

*  1 总览
 *  2 RDB持久化
 *   *  2.1 RDB文件的创建与载入
     *  2.2 自动间隔性保存RDB文件
     *  2.3 RDB文件结构
     *  2.4 分析RDB文件
     *  2.5 RDB持久化总结
 *  3 AOF持久化
 *   *  3.1 什么是AOF持久化
     *  3.2 AOF持久化的实现
     *   *  1 命令追加
         *  2 AOF文件的写入与同步
     *  3.3 AOF文件的载入与数据还原
     *  3.4 AOF重写
     *  3.5 AOF持久化总结

看CyC2018的Redis部分时候，不明白两种持久化是什么怎么做的。  
今天看到了《Redis设计与实现》，直接先从持久化看。

# 1 总览 #

**什么是持久化？**  
Redis是一个**内存型数据库**，其数**据库状态储存在内存中**，一旦服务器进程退出，服务器中的数据库状态也会消失。所以我们需要把储存在内存中的数据库状态保存到**磁盘**里面，避免数据意外丢失。

# 2 RDB持久化 #

**RDB持久化**  
这个功能可以将Redis在内存中的 **数据库状态** 保存在**磁盘**里面，**避免数据意外丢失**。

**两种方式**

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

**RDB文件**  
RDB持久化功能生成的RDB文件是一个经过 **压缩** 的\*\* 二进制文件\*\*，通过该文件可以 **还原** 生成RDB文件时的数据库状态。  
![20190715202139750.png][]  
可以看出RDB文件应该是采用的**无损压缩方式**。

> 所谓无损压缩格式，是利用数据的统计冗余进行压缩，可完全恢复原始数据而不引起任何失真，但压缩率是受到数据统计冗余度的理论限制，一般为2:1到5:1.这类方法广泛用于文本数据，程序和特殊应用场合的图像数据（如指纹图像，医学图像等）的压缩。

RDB文件保存在**硬盘**里面，所以即使Redis服务器进程退出，甚至宕机，只要RDB文件存在，Redis服务器就可以用它还原数据库状态。

## 2.1 RDB文件的创建与载入 ##

**1 两个Redis命令用于生成RDB文件**

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

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

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

fork()函数以前学操作系统的时候遇到过：

> 一个现有进程可以**调用fork函数创建一个新进程**。由fork创建的新进程被称为子进程（child process）。  
> fork调用的一个奇妙之处就是它仅仅**被调用一次，却能够返回两次**，它可能有三种不同的返回值：  
> 1）**在父进程中，fork返回新创建子进程的进程ID；**  
> 2）**在子进程中，fork返回0；**  
> 3）如果出现错误，fork返回一个负值；  
> 在fork函数执行完毕后，如果创建新进程成功，则出现两个进程，一个是子进程，一个是父进程。在子进程中，fork函数返回0，在父进程中，fork返回新创建子进程的进程ID。我们可以通过fork返回的值来判断当前进程是子进程还是父进程。

**2 RDB文件的载入**

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

另外，因为**AOF文件更新频率通常比RDB文件更新频率高**：

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

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

## 2.2 自动间隔性保存RDB文件 ##

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

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

save 900 1
    save 300 10
    save 60 10000

即只要满足下面条件之一，BGSAVE命令就会被执行：  
服务器900s之内，对数据库进行了至少1次修改。  
服务器300s之内，对数据库进行了至少10次修改。  
服务器60s之内，对数据库进行了至少10000次修改。  
![在这里插入图片描述][20190715205521705.png]

**2 具体底层设计与实现**

简而言之redisServer结构里维护了一个**saveparam数组**，该数组用于存储save选项设置的保存条件。  
![20190715205853435.png][]  
redisServer结构里还维护着一个 **dirty计数器** 和一个 **lastsave属性**。前者记录距离上次SAVE或BGSAVE之后服务器对数据库状态进行了多少次修改。后者是一个UNIX时间戳，记录服务器上一次成功执行SAVE或BGSAVE命令的时间。

serverCron函数默认每隔100ms执行一次，该函数用于对正在运行的服务器进行维护，其中一项工作就是检查save选项的条件是否满足，满足就执行BGSAVE：

def serverCron():
    	# 遍历所有保存条件
    	for saveparam in server.saveparams:
    		# 计算距离上次保存操作有多久
    		save_interval =  unixtime_now() - server.lastsave
    		# 满足save选项的条件则执行BGSAVE
    		if server.dirty >= saveparam.changes and save_interval > saveparam.seconds:
    			BGSAVE()

## 2.3 RDB文件结构 ##

RDB文件最开头是REDIS部分，长度5字节，保存“REDIS”五个字符。通过这五个字符，程序在载入文件时，快速检查所载入的是否是RDB文件。（类似JAVA的魔数？）  
![20190715210826514.png][]  
![20190715210944990.png][]

**database部分：**  
![20190715211224808.png][]  
![20190715211257843.png][]  
![2019071521134570.png][]

**key\_value\_pairs部分：**  
![20190715211427401.png][]  
![20190715211448197.png][]  
![20190715211516414.png][]

**value的编码：**  
![20190715211621751.png][]  
![2019071521164099.png][]  
![20190715211658239.png][]  
![20190715211801914.png][]  
![2019071521181631.png][]  
还有很多种类型，基本参照 len + 具体内容 的形式。不再赘述，看书去。（P129）

## 2.4 分析RDB文件 ##

![20190715212017893.png][]  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhcmxpbmd3b29kMjAxMw_size_16_color_FFFFFF_t_70][]

## 2.5 RDB持久化总结 ##

*  **RDB文件** 用于 **保存和还原** Redis服务器所有数据库中的所有 **键值对数据**。
 *  **SAVE命令** 由 **服务器进程** 直接执行保存操作，所以该命令会**阻塞服务器**。
 *  **BGSAVE命令** 由 **子进程** 执行保存操作，该命令**不会阻塞服务器**。
 *  服务器状态中会保存所有用 **save选项** 设置的保存条件，当 **任意一个** 保存条件被满足时，服务器会 **自动执行BGSAVE命令**。
 *  RDB文件是一个 **经过压缩的二进制文件**，由多个部分组成。
 *  对于不同类型的键值对，RDB文件会使用不同的方式来保存他们。

# 3 AOF持久化 #

*  AOF持久化是通过保存 **Redis服务器所执行的写命令** 来记录数据库状态的。
 *  这与RDB持久化不同，RDB持久化是通过保存 **数据库中的键值对** 来记录数据库的。  
    ![20190801112424401.png][]

## 3.1 什么是AOF持久化 ##

举个栗子，如果我们对空白数据库执行以下谢明令，那么数据库中将包含三个键值对：  
![20190801112651269.png][]

*  RDB持久化保存数据库状态的方式是将msg、fruits、numbers三个键的键值对保存到RDB文件中；
 *  而AOF持久化保存数据库状态的方法则是将服务器执行的**SET、SADD、RPUSH三个命令保存到AOF文件中**。

**保存格式**

被写入AOF文件的所有命令都是以Redis的命令请求协议格式保存的，Redis的命令请求协议是纯文本格式。

对上面的三个写命令，AOF内容如下：  
![20190801113151451.png][]

*  其中SELECT命令用于指定数据库，是服务器自动添加的。
 *  其他都是之前通过客户端发送的命令。

服务器在启动时，可以通过载入和执行AOF文件中保存的命令来还原服务器关闭之前的数据库状态，下面是服务器载入AOF文件并还原数据库状态时打印的日志：  
![20190801113508845.png][]

## 3.2 AOF持久化的实现 ##

AOF持久化功能实现可以分为三个步骤：

*  追加（append）
 *  文件写入
 *  文件同步（sync）

### 1 命令追加 ###

在 redisServer 结构中维护了一个sds类型的AOF缓冲区 aof\_buf：

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

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

举个栗子，如果客户端向服务器发送以下命令：

redis> SET KEY VALUE
    OK

那么服务器在执行这个SET命令之后，会将以下协议内容追加到aof\_buf末尾：  
![20190801114403295.png][]

### 2 AOF文件的写入与同步 ###

在命令追加步骤中，我们只看到命令被追加到 aof\_buf 缓冲区中，并没有写入AOF文件，那么什么时候把 aof\_buf 缓冲区内容写入AOF文件中呢？

**flushAppendOnlyFile() 函数**

Redis服务器通过`flushAppendOnlyFile()`函数，考虑是否要将 aof\_buf 中的内容写入和保存到 AOF文件中。

Redis服务器进程是一个事件循环（loop），在这个循环中：

*  文件事件负责接收客户端命令请求，并向客户端发送命令回复。
 *  时间事件负责执行像`serverCron`函数这样需要定时运行的函数。

服务器在处理文件事件时可能会执行写命令，使一些内容被追加到aof\_buf缓冲区里面，所以在服务器每次结束一个事件循环前，都会调用`flushAppendOnlyFile()`函数，考虑是否要将 aof\_buf 中的内容写入和保存到 AOF文件中：

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

**appendfsync 选项**

`flushAppendOnlyFile()`函数的行为由服务器配置的`appendfsync`选项的值来决定：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhcmxpbmd3b29kMjAxMw_size_16_color_FFFFFF_t_70 1][]  
`appendfsync`选项的默认值是`everysec`。

举个栗子，假设服务器在处理文件时间期间，执行了以下三个写入命令：  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhcmxpbmd3b29kMjAxMw_size_16_color_FFFFFF_t_70 2][]  
如果这时`flushAppendOnlyFile()`函数被调用，假设服务器当前的`appendfsync`选项的值为`everysec`，并且距离上次同步AOF文件已经超过一秒钟，那么服务器会先将`aof_buf`中的内容写入到AOF文件中，然后再对AOF文件进行同步。

**文件的写入和同步**

> 为了提高文件的写入效率，在现代操作系统中，当用户调用write函数，将一些数据写入到文件的时候，OS通常会将写入数据暂时保存在一个 **内存缓冲区** 里面，等到缓冲区的空间被填满、或者超过了指定的时限之后，**才真正地将缓冲区中的数据写入到磁盘里面**。  
> 这种做法虽然提高了效率，但也为写入数据带来了**安全问题**，因为如果计算机发生停机，那么保存在内存缓冲区里面的写入数据将会丢失。  
> 为此，系统提供了**fsync和fdatasync**两个同步函数，它们可以强**制让操作系统立即将缓冲区中的数据写入到硬盘里面**，从而确保写入数据的安全性。

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

服务器配置`appendfsync`选项的值直接决定AOF持久化功能的效率和安全性。  
（这里先不写，后面补上）

## 3.3 AOF文件的载入与数据还原 ##

AOF文件里包含了重建数据库状态所需的所有写命令，所以服务器只要**读入并重新执行一遍AOF文件里保存的写命令**，就可以还原服务器关闭之前的数据库状态。具体步骤如下：

1.  创建一个不带网络连接的伪客户端。
2.  从AOF文件中分析并读取出一条写命令。
3.  使用伪客户端执行被读出的写命令。
4.  一直执行步骤2和步骤3直到AOF文件中的所有写命令都被处理完毕为止。

完成以上步骤之后，AOF文件所保存的数据库状态就会被完整地还原出来。流程图如下：  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhcmxpbmd3b29kMjAxMw_size_16_color_FFFFFF_t_70 3][]  
**不带网络连接的伪客户端**

> 因为Redis命令只能在客户端上下文中执行，而载入AOF文件时所使用的命令直接来源于AOF文件而不是网络连接，所以服务器使用了一个没有网络连接的伪客户端来执行AOF文件保存的写命令，伪客户端执行命令的效果和带网络连接的客户端执行命令的效果完全一样。

## 3.4 AOF重写 ##

## 3.5 AOF持久化总结 ##

[20190715202139750.png]: /images/20211209/f68c0e3cc60c4693a9b37b0ca3155eb3.png
[20190715204709171.png]: /images/20211209/2a45ee224a44482ca1792219941440ab.png
[20190715205521705.png]: /images/20211209/e9b450d1b4674fa09f0b9064324dd980.png
[20190715205853435.png]: /images/20211209/44b7c2405d76482ba15d7a6f3c996346.png
[20190715210826514.png]: /images/20211209/5eda0bb8b1c54bac828c6f1ed8da0726.png
[20190715210944990.png]: /images/20211209/3ae8ef2cda0a4702b896a0c204eff433.png
[20190715211224808.png]: /images/20211209/37bcc63e8c4143aeb2cb37b0e4e998a9.png
[20190715211257843.png]: /images/20211209/eb1956f0b4e045e69bc5b201f01bc9c9.png
[2019071521134570.png]: /images/20211209/c1b48763d34643c980b8d08dc7a24b91.png
[20190715211427401.png]: /images/20211209/bed61fa6bcda42eaa22c5bee498ef5c6.png
[20190715211448197.png]: /images/20211209/215da93ea10a4670816997946df3df16.png
[20190715211516414.png]: /images/20211209/d00d42205478432aa1497a8918c7deee.png
[20190715211621751.png]: /images/20211209/0bd9bbedc4b741d1849abd0da90a863c.png
[2019071521164099.png]: /images/20211209/5186d1db91c243a6a7584b77ce8f1c67.png
[20190715211658239.png]: /images/20211209/229713d1182147929cf026aa096b51b5.png
[20190715211801914.png]: /images/20211209/22ab90b3bfa24b7a859980f78176261c.png
[2019071521181631.png]: /images/20211209/6ec70182c2734072964c457631ca6a5b.png
[20190715212017893.png]: /images/20211209/384aa53f39f847459fce349669e2d864.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhcmxpbmd3b29kMjAxMw_size_16_color_FFFFFF_t_70]: /images/20211209/5e2819b5f1084715bfe189bbaea0d5d5.png
[20190801112424401.png]: /images/20211209/5665be7b016f48a38dd2aa1b5bad2314.png
[20190801112651269.png]: /images/20211209/67ea99afebb14e609e2e243a3d7f8ba4.png
[20190801113151451.png]: /images/20211209/77dca2553a074ae48a9e7cd139a96e24.png
[20190801113508845.png]: /images/20211209/a3e5a788ab144fada0353115d2ac99a0.png
[20190801114403295.png]: /images/20211209/1230772b57264ec0b8433a74889ff87d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhcmxpbmd3b29kMjAxMw_size_16_color_FFFFFF_t_70 1]: /images/20211209/5919979a711841b68e6d5028b911a985.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhcmxpbmd3b29kMjAxMw_size_16_color_FFFFFF_t_70 2]: /images/20211209/dee2ee2ccef446a0b4bab8a2a5d0d462.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhcmxpbmd3b29kMjAxMw_size_16_color_FFFFFF_t_70 3]: /images/20211209/411ef159e8cb4505815a1e59eeabd14f.png