Redis之持久化

蔚落 2022-05-08 00:42 263阅读 0赞

Redis支持`RDB`和`AOF`两种持久化机制。

# RDB #

`RDB`持久化是把当前进程数据生成快照保存到硬盘的过程，可以通过`手动`和`自动`两种方式进行RDB持久化。

## 触发方式 ##

*  **手动触发**

<table> 
 <thead> 
  <tr> 
   <th>命令</th> 
   <th>执行流程</th> 
   <th>执行进程</th> 
   <th>阻塞</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>save</td> 
   <td>阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用 ,由于该命令会阻塞Redis服务进程，因此已被废弃，更多的还是使用<code>bgsave</code></td> 
   <td>父进程处理</td> 
   <td>阻塞</td> 
  </tr> 
  <tr> 
   <td>bgsave</td> 
   <td>Redis进程执行<code>fork</code>操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在<code>fork</code>阶段，一般时间很短。<code>bgsave</code>是当前主流触发RDB持久化的方式</td> 
   <td>子进程处理</td> 
   <td>只有<code>fork</code>阶段阻塞，其余由子进程处理不会阻塞</td> 
  </tr> 
 </tbody> 
</table>

*  **自动触发**

1.  使用save相关配置，如`save m n`。表示m秒内数据集存在n次修改 时，自动触发`bgsave`。
2.  如果从节点执行全量复制操作，主节点自动执行`bgsave`生成RDB文件并发送给从节点
3.  执行`debug reload`命令重新加载Redis时，也会自动触发`save`操作。
4.  默认情况下执行`shutdown`命令时，如果没有开启AOF持久化功能则自动执行`bgsave`。

## 执行流程 ##

![在这里插入图片描述][4c264c91c28af51137f0430f7922c8cb.png]

如下是`bgsave`的主要方法的执行逻辑：

1.  执行`bgsave`命令， Redis父进程判断当前是否存在正在执行的子进程， 如RDB/AOF子进程， 如果存在直接返回
2.  父进程执行`fork`操作创建子进程， fork操作过程中父进程会**阻塞**
3.  父进程`fork`完成后， `bgsave`命令返回“Background saving started”信息并不再阻塞父进程， 可以继续响应其他命令
4.  子进程创建RDB文件， 根据父进程内存生成临时快照文件， 完成后对原有文件进行**原子替换**
5.  进程发送信号给父进程表示完成， 父进程更新统计信息

**rdb相关参数**

<table> 
 <thead> 
  <tr> 
   <th>命令</th> 
   <th>功能</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><code>info stats</code>命令查看<code>latest_fork_usec</code></td> 
   <td>获取最近一个<code>fork</code>操作的耗时， 单位为微秒</td> 
  </tr> 
  <tr> 
   <td><code>lastsave</code>命令查看<code>rdb_last_save_time</code></td> 
   <td>获取最后一次生成RDB的时间</td> 
  </tr> 
  <tr> 
   <td><code>info persistence</code>命令查看rdb*相关参数</td> 
   <td>-</td> 
  </tr> 
 </tbody> 
</table>

**优点**

*  RDB是一个紧凑压缩的`二进制`文件， 代表Redis在某个时间点上的数据快照。 非常适用于`备份， 全量复制`等场景进行有效灾备。
 *  由于是紧凑压缩的`二进制`文件，因此Redis加载RDB恢复数据远远快于AOF的方式。

**缺点**

*  `数据无法实时持久化/秒级持久化`。 因为bgsave每次运行都要执行fork操作创建子进程， 属于重量级操作， 频繁执行成本过高。
 *  `存在老版本无法兼容新版RDB格式`。RDB文件使用特定二进制格式保存，演进过程中有多个格式的RDB版本。

# AOF #

AOF（`append only file`）与RDB保持数据库键值对对象的二进制文本不同，它采用记录Redis的`文本格式命令`的形式进行持久化。

## 执行频率 ##

可以通过`appendfsync`控制

<table> 
 <thead> 
  <tr> 
   <th>参数值</th> 
   <th>执行效果</th> 
   <th>刷盘策略</th> 
   <th>性能</th> 
   <th>数据安全</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>always</td> 
   <td>每次写入都要同步AOF文件，在一般的SATA硬盘 上，Redis只能支持大约几百TPS写入，显然跟Redis高性能特性背道而驰，不建议配置</td> 
   <td>命令写入aof_buff缓冲区后立刻调用系统<code>fsync</code>进行刷盘进行持久化后返回</td> 
   <td>低</td> 
   <td>高</td> 
  </tr> 
  <tr> 
   <td>everysec</td> 
   <td>建议的同步策略，也是默认配置，做到兼顾性能和 数据安全性。理论上只有在系统突然宕机的情况下丢失1秒的数据。（严格来说最多丢失1秒数据是不准确的)</td> 
   <td>命令写入<code>aof_buff</code>缓冲区后，调用系统<code>write</code>后返回，由专门线程控制调用<code>fsync</code>进行刷盘持久化</td> 
   <td>一般</td> 
   <td>较安全</td> 
  </tr> 
  <tr> 
   <td>no</td> 
   <td>由于操作系统每次同步AOF文件的周期不可控，而且会加大每次同步硬盘的数据量，虽然提升了性能，但数据安全性无法保证</td> 
   <td>命令写入<code>aof_buff</code>缓冲区后，调用系统<code>write</code>后返回，刷盘由操作系统控制，一般同步周期为30秒</td> 
   <td>高</td> 
   <td>低</td> 
  </tr> 
 </tbody> 
</table>

> `write`操作会触发延迟写（delayed write）机制。Linux在内核提供页缓 冲区用来提高硬盘IO性能。write操作在写入系统缓冲区后直接返回。同步硬盘操作依赖于系统调度机制，例如：缓冲区页空间写满或达到特定时间周期。同步文件之前，如果此时系统故障宕机，缓冲区内数据将丢失。  
> `fsync`针对单个文件操作（比如AOF文件），做**强制硬盘同步**，fsync将 阻塞直到写入硬盘完成后返回，保证了数据持久化  
> 感兴趣的话，可以参考下**mysql**的刷盘机制进行对比

## 执行流程 ##

AOF的执行流程主要有：`命令写入 （append）`、`文件同步（sync）`、`文件重写（rewrite）`、`重启加载 （load）`

![在这里插入图片描述][e949a05471ae657b1b74ae647d984c09.png]

1.  所有的写入命令会追加到`aof_buf`（缓冲区）中。
2.  AOF缓冲区根据对应的策略向硬盘做同步操作。
3.  随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩 的目的。
4.  当Redis服务器重启时，可以加载AOF文件进行数据恢复。

## 重写压缩 ##

随着命令不断写入AOF，文件会越来越大，为了减少存储占用和更快地在重启阶段加载Redis，Redis 引入AOF`重写机制`压缩文件体积。

> **压缩文件空间的来源：**
> 
>  *  **过期**数据不再写入
>  *  **覆盖重复执行命令**后只保留最终命令。如`set key aaa，set key bbb`
>  *  **合并**命令，如`lpush list a、lpush list b、lpush list c`可以转化为`lpush list a b c`

### 触发机制 ###

如下图，是`重写压缩`的执行流程

![在这里插入图片描述][5e8878423a4cef0789cd240d6792b48a.png]

*  `fork`子进程处理aof文件重写工作
 *  父进程接收命令后会双写`aof_buff`、`aof_rewrite_buff`这两块缓冲区，以确保重写过程也可以接收新命令，防止命令丢失
 *  最终新重写压缩的AOF文件会**覆盖**旧AOF文件，达到节省空间的目的

重写机制的触发也分为**手动**和**自动**两种。

*  **手动触发**

直接调用`bgrewriteaof`命令。

*  **自动触发**

根据`auto-aof-rewrite-min-size`和`auto-aof-rewrite-percentage`参数确定自动触发时机。

*  `auto-aof-rewrite-min-size` 表示运行AOF重写时文件最小体积，默认 为64MB。
 *  `auto-aof-rewrite-percentage` 代表当前AOF文件空间 （aof\_current\_size）和上一次重写后AOF文件空间（aof\_base\_size）的比 值。
 *  自动触发时机 = aof\_current\_size>auto-aof-rewrite-min- size &&（aof\_current\_size-aof\_base\_size）/aof\_base\_size>=auto-aof-rewrite- percentage

## 优缺点 ##

*  **优点**
    
     *  基于Redis`命令文本格式`，有较好的可读性
     *  不需要像rdb那样进行`序列化`二次处理，实现简单
     *  提供了较为灵活的`appendfsync`刷盘策略控制
 *  **缺点**
    
     *  直接存储，没有进行压缩，占用空间大（但是也提供了`rewrite`机制进行压缩控制）
     *  由于是文本命令的直接操作回放，重载恢复数据比rdb时间长

# 重启加载 #

如下是重启加载持久化文件数据到内存的执行流程，会**优先**加载`AOF文件`，如果加载不成功会尝试加载`RDB文件`

/* Function called at startup to load RDB or AOF file in memory. */
    void loadDataFromDisk(void) {
        // 记录开始时间
        long long start = ustime();
    
        // AOF 持久化已打开？
        if (server.aof_state == REDIS_AOF_ON) {
            // 尝试载入 AOF 文件
            if (loadAppendOnlyFile(server.aof_filename) == REDIS_OK)
                // 打印载入信息，并计算载入耗时长度
                redisLog(REDIS_NOTICE,"DB loaded from append only file: %.3f seconds",(float)(ustime()-start)/1000000);
        // AOF 持久化未打开
        } else {
            // 尝试载入 RDB 文件
            if (rdbLoad(server.rdb_filename) == REDIS_OK) {
                // 打印载入信息，并计算载入耗时长度
                redisLog(REDIS_NOTICE,"DB loaded from disk: %.3f seconds",
                    (float)(ustime()-start)/1000000);
            } else if (errno != ENOENT) {
                redisLog(REDIS_WARNING,"Fatal error loading the DB: %s. Exiting.",strerror(errno));
                exit(1);
            }
        }
    }

# 总结 #

*  基于rdb文件的`bgsave`和基于aof文件的`bgrewriteaof`会彼此阻塞，当有一方执行时另一方被禁止执行，双方都是通过`fork`子进程进行的并不存在冲突，这里只是性能考虑而这样进行设计的
 *  Redis无论在哪种持久化机制下，即使在Redis中最可靠的持久化方式也无法保证100%可靠，只能是相对可靠。当`appendfsync`刷盘策略开启为`always`可以保证每次写入缓冲区后立刻调用`fsync`刷盘持久化，但是这并不是一个原子性操作，中间出现异常便持久化失败
 *  我们通常会充分利用Redis的高性能，把它作为一个支持多种数据结构的纯缓存中间件来进行使用，一般情况下为了追求高性能会牺牲持久性方面的考虑

[4c264c91c28af51137f0430f7922c8cb.png]: /images/20220508/a21444fccc214672bf32768759411914.png
[e949a05471ae657b1b74ae647d984c09.png]: /images/20220508/af5cdc0d3dc244feb929d695b66397f8.png
[5e8878423a4cef0789cd240d6792b48a.png]: /images/20220508/1e5738945997424594e8bd0da20799e3.png