Redis深入学习（三）：持久化

港控/mmm° 2022-10-13 05:14 152阅读 0赞

### 文章目录 ###

*  一、RDB
 *   *  1.1 RDB 简介
     *  1.2 触发方式
     *  1.3 恢复数据
     *  1.4 停止 RDB 持久化
     *  1.5 RDB 的优势和劣势
 *  二、AOF
 *   *  2.1 AOF 简介
     *  2.2 开启 AOF
     *  2.3 AOF 文件恢复
     *  2.4 AOF 重写
     *  2.5 AOF 的优缺点
 *  三、持久化方式的选择

> 本文参考：https://www.cnblogs.com/ysocean/tag/Redis%E8%AF%A6%E8%A7%A3/

由于`Redis`是一个内存数据库，所谓内存数据库，就是将数据库中的内容保存在内存中，这与传统的`MySQL`，`Oracle`等关系型数据库直接将内容保存到硬盘中相比，内存数据库的读写效率比传统数据库要快的多（内存的读写效率远远大于硬盘的读写效率）。但是保存在内存中也随之带来了一个缺点，一旦断电或者宕机，那么内存数据库中的数据将会全部丢失。

为了解决这个缺点，`Redis`提供了将内存数据持久化到硬盘，以及用持久化文件来恢复数据库数据的功能。`Redis`支持两种形式的持久化，一种是 `RDB`快照（`snapshotting`），另外一种是`AOF`（`append-only-file`）。

# 一、RDB #

## 1.1 RDB 简介 ##

`RDB`是`Redis`用来进行持久化的一种方式，是把当前内存中的数据集快照写入磁盘，也就是`Snapshot`快照（数据库中所有键值对数据），恢复时是将快照文件直接读到内存里。

## 1.2 触发方式 ##

**① 自动触发**

详情见[ Redis 配置文件\#6][Redis _6]

**② 手动触发**

手动触发`Redis`进行`RDB`持久化的命令有两种：

<table> 
 <thead> 
  <tr> 
   <th>命令</th> 
   <th>说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>save</td> 
   <td>该命令会阻塞当前 Redis 服务器，执行 save 命令期间，Redis 不能处理其他命令，直到 RDB 过程完成为止。显然该命令对于内存比较大的实例会造成长时间阻塞，这是致命的缺陷，为了解决此问题，Redis 提供了第二种方式。</td> 
  </tr> 
  <tr> 
   <td>bgsave</td> 
   <td>执行该命令时，Redis 会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体操作是Redis 进程执行 fork 操作创建子进程，RDB 持久化过程由子进程负责，完成后自动结束。阻塞只发生在 fork 阶段，一般时间很短。基本上 Redis 内部所有的 RDB 操作都是采用 bgsave 命令。</td> 
  </tr> 
 </tbody> 
</table>

> 执行执行 flushall 命令，也会产生dump.rdb文件，但里面是空的。

## 1.3 恢复数据 ##

将备份文件 (`dump.rdb`) 移动到`redis`安装目录并启动服务即可，`redis`就会自动加载文件数据至内存了。`Redis`服务器在载入`RDB`文件期间，会一直处于阻塞状态，直到载入工作完成为止。

获取`redis`的安装目录可以使用`config get dir`命令：  
![在这里插入图片描述][20210707203827190.png]  
载入的标识是如下命令：  
![在这里插入图片描述][20210707203912423.png]

## 1.4 停止 RDB 持久化 ##

有些情况下，我们只想利用`Redis`的缓存功能，并不像使用`Redis`的持久化功能，那么这时候我们最好停掉`RDB`持久化。可以通过上面讲的在配置文件`redis.conf`中，可以注释掉所有的`save`行来停用保存功能或者直接一个空字符串来实现停用：`save ""`，也可以通过命令：`redis-cli config set save " "`

## 1.5 RDB 的优势和劣势 ##

**① 优势**

1.  `RDB`是一个非常紧凑(`compact`)的文件，它保存了`redis`在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。
2.  生成`RDB`文件的时候，`redis`主进程会`fork()`一个子进程来处理所有保存工作，主进程不需要进行任何磁盘`IO`操作。
3.  `RDB`在恢复大数据集时的速度比`AOF`的恢复速度要快。

**② 劣势**

1.  `RDB`方式数据没办法做到实时持久化/秒级持久化。因为`bgsave`每次运行都要执行`fork`操作创建子进程，属于重量级操作，如果不采用压缩算法(内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑)，频繁执行成本过高(影响性能)
2.  `RDB`文件使用特定二进制格式保存，`Redis`版本演进过程中有多个格式的`RDB`版本，存在老版本`Redis`服务无法兼容新版`RDB`格式的问题(版本不兼容)
3.  在一定间隔时间做一次备份，所以如果`Redis`意外`down`掉的话，就会丢失最后一次快照后的所有修改(数据有丢失)

# 二、AOF #

## 2.1 AOF 简介 ##

`Redis`的持久化方式之一`RDB`是通过保存数据库中的键值对来记录数据库的状态。而另一种持久化方式`AOF`则是通过保存`Redis`服务器所执行的写命令来记录数据库状态。

比如对于如下命令：  
![在这里插入图片描述][20210707210806628.png]  
`Redis`持久化方式就是将`str1`、`str2`、`str3`这三个键值对保存到`RDB`文件中，而`AOF`持久化则是将执行的`set`、`sadd`、`lpush`三个命令保存到`AOF`文件中。

## 2.2 开启 AOF ##

`AOF`配置详情见[ Redis 配置文件\#11][Redis _6]

开启`AOF`：将`redis.conf`的`appendonly`配置改为`yes`即可。

`AOF`保存文件的位置和`RDB`保存文件的位置一样，都是通过`redis.conf`配置文件的`dir`配置：  
![在这里插入图片描述][20210707212330308.png]  
可以通过`config get dir`命令获取保存的路径。

## 2.3 AOF 文件恢复 ##

重启`Redis`之后就会进行`AOF`文件的载入。

异常修复命令：`redis-check-aof --fix`进行修复。

## 2.4 AOF 重写 ##

由于`AOF`持久化是`Redis`不断将写命令记录到`AOF`文件中，随着`Redis`不断的进行，`AOF`的文件会越来越大，文件越大，占用服务器内存越大以及 `AOF`恢复要求时间越长。为了解决这个问题，`Redis`新增了重写机制，当`AOF`文件的大小超过所设定的阈值时，`Redis`就会启动`AOF`文件的内容压缩，只保留可以恢复数据的最小指令集。可以使用命令`bgrewriteaof`来重新。

比如对于如下命令：  
![在这里插入图片描述][20210707212800308.png]  
如果不进行`AOF`文件重写，那么`AOF`文件将保存四条`SADD`命令，如果使用`AOF`重写，那么AOF 文件中将只会保留下面一条命令：`sadd animals "dog" "tiger" "panda" "lion" "cat"`。

**也就是说`AOF`文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的`AOF`文件**。

`AOF`文件重写触发机制：通过`redis.conf`配置文件中的`auto-aof-rewrite-percentage`：默认值为100，以及`auto-aof-rewrite-min-size`：64 mb 配置，也就是说默认`Redis`会记录上次重写时的`AOF`大小，默认配置是当`AOF`文件大小是上次`rewrite`后大小的一倍且文件大于64 M 时触发。

这里再提一下，我们知道`Redis`是单线程工作，如果 重写`AOF`需要比较长的时间，那么在重写`AOF`期间，`Redis`将长时间无法处理其他的命令，这显然是不能忍受的。`Redis`为了克服这个问题，解决办法是将`AOF`重写程序放到子程序中进行，这样有两个好处：

1.  子进程进行`AOF`重写期间，服务器进程（父进程）可以继续处理其他命令。
2.  子进程带有父进程的数据副本，使用子进程而不是线程，可以在避免使用锁的情况下，保证数据的安全性。

使用子进程解决了上面的问题，但是新问题也产生了：因为子进程在进行 `AOF`重写期间，服务器进程依然在处理其它命令，这新的命令有可能也对数据库进行了修改操作，使得当前数据库状态和重写后的`AOF`文件状态不一致。

为了解决这个数据状态不一致的问题，`Redis`服务器设置了一个`AOF`重写缓冲区，这个缓冲区是在创建子进程后开始使用，当`Redis`服务器执行一个写命令之后，就会将这个写命令也发送到`AOF`重写缓冲区。当子进程完成 `AOF`重写之后，就会给父进程发送一个信号，父进程接收此信号后，就会调用函数将`AOF`重写缓冲区的内容都写到新的`AOF`文件中。

这样将`AOF`重写对服务器造成的影响降到了最低。

## 2.5 AOF 的优缺点 ##

**① 优势**

1.  `AOF`持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，`Redis`最多也就丢失 1 秒的数据而已。
2.  `AOF`文件使用`Redis`命令追加的形式来构造，因此，即使`Redis`只能向 `AOF`文件写入命令的片断，使用`redis-check-aof`工具也很容易修正`AOF`文件。
3.  `AOF`文件的格式可读性较强，这也为使用者提供了更灵活的处理方式。例如，如果我们不小心错用了`FLUSHALL`命令，在重写还没进行时，我们可以手工将最后的`FLUSHALL`命令去掉，然后再使用`AOF`来恢复数据。

**② 劣势**

1.  对于具有相同数据的的`Redis`，`AOF`文件通常会比`RDB`文件体积更大。
2.  虽然`AOF`提供了多种同步的频率，默认情况下，每秒同步一次的频率也具有较高的性能。但在`Redis`的负载较高时，`RDB`比`AOF`具好更好的性能保证。
3.  `RDB`使用快照的形式来持久化整个`Redis`数据，而`AOF`只是将每次执行的命令追加到`AOF`文件中，因此从理论上说，`RDB`比`AOF`方式更健壮。官方文档也指出，`AOF`的确也存在一些`BUG`，这些`BUG`在`RDB`没有存在。

# 三、持久化方式的选择 #

那么对于`AOF`和`RDB`两种持久化方式，我们应该如何选择呢？

如果可以忍受一小段时间内数据的丢失，毫无疑问使用`RDB`是最好的，定时生成`RDB`快照（`snapshot`）非常便于进行数据库备份， 并且`RDB`恢复数据集的速度也要比`AOF`恢复的速度要快，而且使用`RDB`还可以避免`AOF`一些隐藏的`bug`；否则就使用`AOF`重写。但是一般情况下建议不要单独使用某一种持久化机制，而是应该两种一起用，在这种情况下，当`Redis`重启的时候会优先载入`AOF`文件来恢复原始的数据，因为在通常情况下`AOF`文件保存的数据集要比`RDB`文件保存的数据集要完整。

**RDB-AOF混合持久化**

在`Redis4.0`之后，新增了`RDB-AOF`混合持久化方式。这种方式结合了`RDB`和`AOF`的优点，既能快速加载又能避免丢失过多的数据。

具体配置为：`aof-use-rdb-preamble`，设置为`yes`表示开启，设置为`no`表示禁用。

当开启混合持久化时，主进程先`fork`出子进程将现有内存副本全量以`RDB`方式写入`aof`文件中，然后将缓冲区中的增量命令以`AOF`方式写入`aof`文件中，写入完成后通知主进程更新相关信息，并将新的含有`RDB`和`AOF`两种格式的`aof`文件替换旧的`aof`文件。

简单来说：混合持久化方式产生的文件一部分是`RDB`格式，一部分是`AOF`格式。这种方式优点我们很好理解，缺点就是不能兼容`Redis4.0`之前版本的备份文件了。

[Redis _6]: https://blog.csdn.net/qq_38697437/article/details/118082183
[20210707203827190.png]: /images/20221005/30080f3dc5ce4eda96fd064f73a98ccc.png
[20210707203912423.png]: /images/20221005/6250cac837fb4ab8bd5d37cc9eb2c26b.png
[20210707210806628.png]: /images/20221005/ebdfa8758cb44640a7ac6bb29f258121.png
[20210707212330308.png]: /images/20221005/b3822e9ceea049b4b7a2deee31681583.png
[20210707212800308.png]: /images/20221005/741675759d27438786e39ab9bd270d73.png