Redis 持久化 —— 超详细操作演示！

﹏ヽ暗。殇╰゛Y 2024-02-05 11:55 8阅读 0赞

#### 四、Redis 持久化 ####

*   *  四、Redis 持久化
     *   *  4.1 持久化基本原理
         *  4.2 RDB持久化
         *  4.3 AOF持久化
         *  4.4 RDB与AOF对比
         *  4.5 持久化技术转型

> **数据库系列文章：**  
>   
> **关系型数据库**:
> 
>  *  [MySQL —— 基础语法大全][MySQL _]
>  *  [MySQL —— 进阶][MySQL _ 1]
> 
>   
> **非关系型数据库**:
> 
>  *  [Redis 的安装与配置][Redis]
>  *  [Redis 基本命令（上）][Redis 1]
>  *  [Redis 基本命令（下）][Redis 2]

### 四、Redis 持久化 ###

Redis是一个**内存数据库**，所以其运行效率非常高。但也 **存在一个问题**：内存中的数据是不持久的，若 **主机宕机** 或 **Redis 关机重启**，则内存中的数据全部丢失。当然，这是不允许的。 Redis **具有持久化功能**，其会按照设置以 **快照** 或 **操作日志** 的形式将数据持久化到磁盘。

根据持久化使用技术的不同，Redis 的**持久化分为两种**： `RDB`（`Redis DataBase`） 与 `AOF` （`Append Only File`）。

#### 4.1 持久化基本原理 ####

![在这里插入图片描述][5accbd3a4a1d45cc88764ab3e3bfccaa.png]  
    Redis **持久化** 也称为 **钝化**， 是指将内存中数据库的**状态描述信息**保存到磁盘中。只不过是不同的持久化技术，对数据的**状态描述信息是不同的** ，生成的**持久化文件**也是不同的 。但它们的作用都是相同的：避免数据意外丢失。

通过**手动方式**，或 **自动定时方式**，或 **自动条件触发方式**，将内存中数据库的**状态描述信息**写入到指定的持久化文件中。当系统重新启动时，**自动加载** **持久化文件**，并根据文件中数据库状态描述信息将数据恢复到内存中 ，这个数据恢复过程也称为**激活** 。这个 **钝化** 与 **激活** 的过程就是 Redis 持久化的基本原理。

不过从以上分析可知， 对于 Redis **单机状态**下， 无论是手动方式，还是定时方式或条件触发方式，都存在数据丢失问题： 在**尚未**手动自动保存时发生了 Redis 宕机状况，那么从上次保存到宕机期间产生的数据就会丢失。不同的持久化方式，其**数据的丢失率**也是不同的。

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

需要注意的是， RDB 是 **默认持久化方式**，但 Redis 允许 RDB 与 AOF 两种持久化技术同时开启，此时系统会使用 AOF 方式做持久化，即 **AOF 持久化技术**的 **优先级要更高**。同样的道理，两种技术同时开启状态下， 系统启动时若两种持久化文件同时存在，则 **优先加载** AOF持久化文件。

#### 4.2 RDB持久化 ####

**RDB**，`Redis DataBase` ，是指将内存中某一时刻的 **数据快照** **全量** 写入到指定的 `rdb 文件` 的持久化技术。 RDB 持久化默认是开启的。 当 Redis 启动时会 **自动读取** **RDB 快照文件**，将数据从硬盘载入到内存， 以恢复 Redis 关机前的数据库状态。

**⭐️ 4.2.1、持久化的执行**

RDB持久化的执行有三种方式：`手动 save 命令`、`手动 bgsave 命令`，与`自动条件触发`。

**(1) 手动 save 命令**

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

通过在 `redis-cli` 客户端中执行 `save` 命令可**立即**进行一次**持久化保存**。 `save` 命令在**执行期间**会 **阻塞** `redis-server` 进程，**直至持久化过程完毕**。而在 `redis-server` 进程阻塞期间， Redis **不能**处理任何读写请求，无法对外提供服务。

**(2) 手动 bgsave 命令**

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

通过在 `redis-cli` 客户端中执行 `bgsave` 命令可**立即**进行一次**持久化保存**。不同于 `save` 命令的是，正如该命令的名称一样， `background save` ，后台运行 `save` 。 `bgsave` 命令会使服务器进程 `redis-server` 生成一个 **子进程**，由该子进程**负责完成保存过程** 。在子进程进行保存过程中，不会阻塞 `redis-server` 进程对客户端读写请求的处理。

**(3) 自动条件触发**

自动条件触发的本质仍是 `bgsave` 命令的执行。只不过是用户通过在**配置文件**中做相应的设置后， Redis 会根据设置信息**自动调用** `bgsave` 命令执行。具体配置方式，后面会详解。

**(4) 查看持久化时间**

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

通过 `lastsave` 命令可以**查看最近一次执行持久化的时间** ，其返回的是一个 `Unix` **时间戳** （`ms`）。

**⭐️ 4.2.2、RDB优化配置**（**重要 ！！！**）

RDB 相关的配置在 `redis.conf` 文件的 `SNAPSHOTTING` 部分。

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

**(1) save**

> 该配置用于设置**快照的自动保存触发条件**，即 `save point` ，**保存点**。该触发条件是在指定时间段内发生了指定次数的写操作。 除非另有规定，默认情况下持久化条件为 `save 3600 1 300 100 60 10000` 。 其等价于以下三条:
> 
>  *  `save 3600 1` \# 在 3600 秒 (1 小时) 内发生 1 次写操作
>  *  `save 300 100` \# 在 300 秒 (5 分钟) 内发生 100 次写操作
>  *  `save 60 10000` \# 在 60 秒 (1 分钟) 内发生 1 万次写操作
> 
> 如果不启用RDB 持久化，只需设置 `save` 的参数为**空串**即可： `save ""`。

**(2) stop-write-on-bgsave-error**

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

> 默认情况下，如果 RDB 快照**已启用**（**至少一个保存点**），且最近的 `bgsave` 命令失败， Redis将**停止接受写入**。这样设置是为了让用户意识到数据没有正确地保存到磁盘上，否则很可能没有人会注意到，并会发生一些灾难 。当然，如果 `bgsave` 命令后来**可以正常工作**了， Redis将自动允许再次写入。

**(3) rdbcompression**

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

> 当进行持久化时启用 `LZF` **压缩字符串对象**。虽然压缩 RDB 文件会消耗系统资源，降低性能，但可大幅降低文件的大小，方便保存到磁盘，加速主从集群中从节点的数据同步。

**(4) rdbchecksum**

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

> 从 RDB5 开始， RDB 文件的 CRC64 **校验和**就被放置在了文件末尾。这使格式更能 **抵抗** RDB文件的损坏，但在保存和加载 RDB 文件时，性能会受到影响（约 10%），因此可以设置为 `no` **禁用校验和**以获得最大性能。
> 
>  *  在禁用校验和的情况下创建的 RDB 文件的校验和为零，这将告诉加载代码**跳过**校验检查。
>  *  默认为 `yes` ，开启了校验功能。

**(5) sanitize-dump-payload**

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

> 该配置用于设置在加载 RDB 文件或进行持久化时**是否开启**对 `zipList` 、 `listPack` 等数据的**全面安全检测**。该检测可以降低命令处理时发生系统崩溃的可能。其可设置的值有三种选择：
> 
>  *  `no` ：**不检测**
>  *  `yes` ：**总是检测**
>  *  `clients` ：只有**当客户端连接时检测**。排除了加载 RDB 文件与进行持久化时的检测。
> 
> 默认值本应该是 `clients` ，但其会影响 Redis 集群的工作，所以默认值为 `no` ，不检测。

**(6) dbfilename**

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

> 指定 RDB 文件的**默认名称**，默认为 `dump.rdb` 。

**(7) rdb-del-sync-files**

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

> **主从复制**时，==**是否删除**==用于同步的从机上的 RDB 文件。默认是 `no` ，**不删除** 。 不过需要注意， 只有当 **从机** 的 RDB 和 AOF 持久化功能 都未开启 时才生效。

**(8) dir**

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

> 指定 RDB 与 AOF 文件的**生成目录**。默认为 Redis **安装根目录**。

**⭐️ 4.2.3、RDB文件结构**

RDB 持久化文件 `dump.rdb` 整体上有**五部分**构成：  
![在这里插入图片描述][d962478715644992a3cda1c8d997e26e.png]

**(1) SOF**

**SOF** (`Start Of File`) 是一个**常量**，一个字符串 `REDIS` ，仅包含这五个字符，其长度为 5 。用于标识 RDB文件的开始，以便在加载 RDB 文件时可以迅速判断出文件是否是 RDB 文件。

**(2) rdb\_version**

这是一个整数，长度为 4 字节，表示 RDB 文件的**版本号**。

**(3) EOF**

**EOF** (`End Of File`) 是一个**常量**，占 1 个字节，用于标识 RDB 数据的结束，**校验和**的开始。

**(4) check\_um**

**校验和** `check_sum` 用于判断 RDB 文件中的内容是否出现 **数据异常**。 其采用的是 `CRC64` 校验算法。

> CRC校验算法：
> 
>  *  在持久化时，先将 `SOF` 、 `rdb_version` 及内存数据库中的 `数据快照` 这三者的二进制数据拼接起来，形成一个二进制数（假设称为数 `a` ），然后再使用这个 `a` 除以校验和 `check_sum` ，此时可获取到一个余数 `b` ，然后再将这个 `b` 拼接到 `a` 的后面，形成 `databases` 。
>  *  在加载时，需要先使用 `check_sum` 对 RDB 文件进行**数据损坏验证**。
>     
>      *  验证过程：只需将 RDB 文件中除 `EOF` 与 `check_sum` 外的数据除以 `check_sum` 。只要除得的余数不是 `0` ，就说明文件发生**损坏**。
>      *  当然，如果余数是 `0` ，也不能肯定文件没有损坏。这种验证算法，是 **数据损坏校验**，而不是数据没有损坏的校验。

**(5) databases**

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

`databases` 部分是 RDB 文件中最重要的**数据部分**，其可以包含**任意多个非空数据库**。而每个 `database` 又是由三部分构成：

*  `SODB` ：是一个常量，占 1 个字节，用于标识一个数据库的**开始**。
 *  `db_number` ：**数据库编号**。
 *  `key_value_pairs` ：当前数据库中的**键值对数据**。

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

每个 `key_value_pairs` 又由很多个用于描述 **键值对** 的数据构成。

*  `VALUE_TYPE` ：是一个常量，占 1 个字节，用于标识该键值对中 `value` 的**类型**。
 *  `EXPIRETIME_UNIT` ：是一个常量，占 1 个字节，用于标识 **过期时间** 的单位是 **`秒`** 还是 **`毫秒`**。
 *  `TIME` ：当前 `key-value` 的**过期时间**。

**⭐️ 4.2.4、RDB持久化过程** (*面试的时候要说清楚过程*)

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

对于Redis 默认的 **RDB 持久化**，在进行 `bgsave` 持久化时， `redis-server` 进程会 `fork` 出一个 `bgsave` **子进程**，由该子进程以 **异步方式** 负责完成持久化。而在持久化过程中， `redis-server` 进程不会阻塞，其会继续**接收并处理**用户的读写请求。  
     `bgsave`子进程的详细工作原理如下：  
     由于**子进程**可以**继承** **父进程**的所有资源，且父进程不能拒绝子进程的继承权。所以，`bgsave` 子 进程有权读取到 `redis-server` 进程写入到内存中的用户数据，使得将内存数据持久化到 `dump.rdb` 成为可能。  
     `bgsave` **子进程** 在持久化时首先会将内存中的**全量数据** `copy` 到磁盘中的一个 RDB **临时文件**， `copy` 结束后，再将该文件 `rename` 为 `dump.rdb` ，**替换掉**原来的**同名文件**。

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

不过，在进行持久化过程中，如果 `redis-server` 进程接收到了用户写请求，则系统会将内存中**发生数据修改的物理块** `copy` 出一个 **副本**。等内存中的**全量数据** `copy` 结束后，会再将**副本**中的数据 `copy` 到 RDB **临时文件**。 这个副本的生成是由于 Linux 系统的 **写时复制技术**（`Copy-On-Write` ）实现的。

> **写时复制技术**是Linux 系统的一种进程管理技术。  
>  
> 
>     **原本**在 `Unix` 系统中，当一个**主进程**通过 `fork()` 系统调用创建**子进程**后，**内核进程** 会 **复制** **主进程**的整个内存空间中的数据，然后分配给**子进程**。这种方式存在的问题有以下几点：
> 
> 1.  这个过程非常耗时
> 2.  这个过程降低了系统性能
> 3.  如果主进程修改了其内存数据，子进程副本中的数据是没有修改的。即出现了数据冗余，而冗余数据最大的问题是数据**一致性**无法保证。  
>      
> 
>     **现代** 的 `Linux` 则采用了更为有效的方 式：**写时复制**。子进程会 **继承** 父进程的**所有资源**，其中就包括主进程的**内存空间**。即子进程与父进程 **共享内存** 。只要内存被**共享** ，那么该内存就是**只读的**（写保护的）。  
>     而 **写时复制** 则是在任何一方需要写入数据到共享内存时都会出现异常，此时内核进程就会将需要写入的数据 `copy` 出一个**副本**写入到另外一块**非共享内存区域**。

#### 4.3 AOF持久化 ####

**AOF**，`Append Only File` ，是指 Redis 将每一次的 **写操作** 都以 **日志的形式** 记录到一个 AOF 文件中的持久化技术。当需要恢复内存数据时，将这些 **写操作重新执行一次**，便会恢复到之前的内存数据状态。

**⭐️ 4.3.1、AOF基础配置**

**(1) AOF 的开启**

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

默认情况下 AOF 持久化是没有开启的，通过修改配置文件中的 `appendonly` 属性为 `yes` 可以开启。

> 如果修改，一般不直接修改配置文件：  
>  ![在这里插入图片描述][eeb0b002fa13422591994acb2990908c.png]
> 
> `config set appendonly yes`  
>    
> 改完支持把缓存内的还要修改 `rewrite` 一下:  
> `config rewrite`  
>  ![在这里插入图片描述][a0d8d0bfe9d0495b9194a7b945bbe9e3.png]

**(2) 文件名配置**

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

Redis 7 在这里发生了重大变化。原来只有一个 `appendonly.aof` 文件，现在具有了三类多个文件：

*  **基本文件**：可以是 `RDB` 格式也可以是 `AOF` 格式。其存放的内容是由 `RDB` 转为 `AOF` 当时内存的**快照数据**。该文件可以有多个。
 *  **增量文件**：以**操作日志形式记录**转为 `AOF` 后的**写入操作**。该文件可以有多个。
 *  **清单文件**：用于维护 `AOF` 文件的**创建顺序**，保障激活时的应用顺序。 该文件只有一个。

**(3) 混合式持久化开启**

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

对于基本文件可以是 `RDF` 格式也可以是 `AOF` 格式。通过 `aof-use-rdb-preamble` 属性可以选择。其默认值为 `yes` ，即**默认 `AOF` 持久化**的基本文件为 `rdb` 格式文件，也就是默认采用**混合式持久化**。

**(4) AOF 文件目录配置**

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

为了方便管理，可以专门为 AOF 持久化文件指定存放目录。目录名由 `appenddirname` 属性指定，存放在 `redis.conf` 配置文件的 `dir` 属性**指定的目录**，默认为 Redis **安装目录**。

**⭐️ 4.3.2、AOF文件格式**

AOF 文件包含三类文件：**基本文件**、**增量文件** 与 **清单文件**。其中**基本文件**一般为 `rdb` 格式，在前面已经研究过了。下面就来看一下 **增量文件** 与 **清单文件** 的内容格式。

**(1) Redis 协议**

**增量文件** 扩展名为 `.aof` ，采用 **AOF 格式**。 AOF 格式其实就是 Redis *通讯协议格式*， AOF持久化文件的 本质就是基于 Redis 通讯协议的文本 ，将命令以纯文本的方式写入到文件中。

Redis 协议规定， Redis 文本是 以**行**来划分 ，每行以 `\r\n` 行结束。每一行都有一个 **消息头**以表示消息类型。 **消息头** 由六种不同的符号表示，其意义如下:

*  (`+`) 表示一个**正确**的状态信息
 *  (`-`) 表示一个**错误**信息
 *  (`*`) 表示消息体总**共有多少行**，不包括当前行
 *  (`$`) 表示下一行 **消息数据 的长度**，不包括换行符长度 `\r\n`
 *  (`空`) 表示一个消息数据
 *  (`:`) 表示返回一个数值

**(2) 查看AOF文件**

打开 `appendonly.aof.1.incr.aof` 文件，可以看到如下格式内容。

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

以上内容中框起来的是三条命令。一条数据库切换命令 `SELECT 0` ，两条 `set` 命令。它们的意义如下：

> `*2`          – 表示当前命令包含 2 个参数  
> `$6`          – 表示第 1 个参数包含 6 个字符  
> `SELECT`    – 第 1 个参数  
> `$1`          – 表示第 2 个参数包含 1 个字符  
> `0`           – 第 2 个参数  
>    
> `*3`          – 表示当前命令包含 3 个参数  
> `$3`           – 表示第 1 个参数包含 3 个字符  
> `set`         – 第 1 个参数  
> `$1`           – 表示第 2 个参数包含 1 个字符  
> `a`             – 第 2 个参数  
> `$10`         – 表示第 3 个参数包含 10 个字符  
> `aaaaaaaaaa`      – 第 3 个参数

**(3) 清单文件**

打开清单文件 `appendonly.aof.manifest` ，查看其内容如下：

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

该文件首先会按照 `seq` 序号列举出所有基本文件，基本文件 `type` 类型为 `b` ，然后再按照 `seq` 序号再列举出**所有增量文件**，增量文件 `type` 类型为 `i` 。

对于 Redis 启动时的数据恢复，也会按照该文件由上到下依次加载它们中的数据。

**⭐️ 4.3.3、Rewrite机制**(*面试经常会问！！！*)

随着使用时间的推移，AOF 文件会越来越大。为了**防止 AOF 文件由于太大**而占用大量的磁盘空间，降低性能， Redis 引入了 `Rewrite` 机制来对 AOF 文件**进行压缩**。

**(1) 何为 rewrite**

所谓 `Rewrite` 其实就是对 **AOF 文件** 进行**重写整理**。当 `Rewrite` 开启后，主进程 `redis-server` 创建出一个**子进程** `bgrewriteaof` ，由该**子进程**完成 `rewrite` 过程。其首先对现有 `aof` 文件进行 `rewrite` 计算，将 **计算结果** 写入到一个**临时文件**，写入完毕后，再 `rename` 该**临时文件**为 **原 `aof`文件名**，**覆盖原有文件**。

**(2) rewrite 计算**

`rewrite` 计算也称为 `rewrite 策略`。 rewrite 计算遵循以下策略：

*  **读操作命令** 不写入文件
 *  **无效命令** 不写入文件
 *  **过期数据** 不写入文件
 *  **多条命令** 合并写入 文件

**(3) 手动开启 rewrite**

`Rewrite` 过程的执行有两种方式。一种是通过 `bgrewriteaof` 命令**手动开启**，一种是通过设置条件**自动开启**。

以下是手动开启方式：

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

该命令会使**主进程** `redis-server` 创建出一个子进程 `bgrewriteaof` ，由该子进程完成 `rewrite`过程。而在 `rewrite` 期间， `redis-server` 仍是可以**对外提供读写服务**的。

**(4) 自动开启 rewrite**

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

手动方式需要人办干预，所以一般采用**自动方式**。由于 `Rewrite` 过程是一个**计算过程**，需要消耗大量系统资源，会降低系统性能。所以， `Rewrite` 过程并不是随时随地任意开启的，而是通过**设置一些条件**，当满足条件后才会启动，以降低对性能的影响。

下面是**配置文件**中对于 `Rewrite` **自动启动条件**的设置。

*  `auto-aof-rewrite-percentage` ：开启 `rewrite` 的增大比例，默认 `100%` 。指定为 `0` ，表示 禁用自动 `rewrite` 。
 *  `auto-aof-rewrite-min-size` ：开启 `rewrite` 的 AOF **文件最小值**，默认 64M 。该值的设置主要是为了**防止小 AOF 文件**被 `rewrite` ，从而导致性能下降。

**自动重写** AOF 文件。当 AOF 日志文件大小增长到**指定的百分比时**， Redis 主进程 `redis-server` 会 `fork`出一个**子进程** `bgrewriteaof` 来完成 `rewrite` 过程。

其工作原理如下：

*  Redis 会记住最新 `rewrite` 后的 AOF 文件大小作为**基本大小**，如果从主机启动后就没有发生过重写，则基本大小就使用启动时 AOF 的大小。
 *  如果当前**AOF 文件** **大于** **基本大小**的配置文件中指定的**百分比阈值**，且当前 **AOF 文件** **大于** 配置文件中指定的**最小阈值**，则会触发 `rewrite` 。

**⭐️ 4.3.4、AOF优化配置**

**(1) appendfsync**

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

当客户端**提交写操作命令**后，该命令就会写入到 `aof_buf` 中，而 `aof_buf` 中的数据持久化到磁盘 AOF 文件的过程称为**数据同步**。  
    何时将 `aof_buf` 中的数据**同步**到 AOF 文件？采用不同的**数据同步策略**，同时的时机是不同的，有三种策略：

*  `always` ：写操作命令写入 `aof_buf` 后会立即调用 `fsync()` 系统函数，将其**追加到** AOF 文件。该策略**效率较低**，但相对比较安全，不会丢失太多数据。最多就是刚刚执行过的写操作在尚未同步时出现宕机或重启，将这一操作丢失。
 *  `no` ：写操作命令写入 `aof_buf` 后什么也不做，不会调用 `fsync()` 函数。而将 `aof_buf` 中的数据同步磁盘的操作由操作系统负责。 Linux 系统默认同步周期为 **30 秒**。效率较高。
 *  `everysec` ：**默认策略**。写操作命令写入 `aof_buf` 后并不直接调用 `fsync()`，而是 **每秒调用一次** `fsync()` 系统函数来完成同步。该策略兼顾到了性能与安全，是一种折中方案。

**(2) no-appendfsync-on-rewrite**

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

该属性用于指定， 当 AOF `fsync` 策略设置为 `always` 或 `everysec` 当**主进程**创建了**子进程** 正在执行 `bgsave` 或 `bgrewriteaof` 时， 主进程是否不调用 `fsync()` 来做数据同步。设置为 `no`，双重否定即**肯定**，主进程会调用 `fsync()` 做同步。而 `yes` 则不会调用 `fsync()` 做数据同步。  
    如果调用 `fsync()`，在需要同步的数据量非常大时，会 **阻塞主进程** 对外提供服务，即会存在**延迟问题**。如果不调用 `fsync()`，则 AOF `fsync` 策略相当于设置为了 `no` ，可能会 存在 30 秒数据丢失的风险。

> 在生产环境中:  
> 如果 **写操作** 有可能出现 **高并发** 的情况，设为 `yes`;  
> 大多数为 **读操作** **高并发**，默认为 `no`。

**(3) aof-rewrite-incremental-fsync**

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

当 `bgrewriteaof` 在执行过程也是先将 `rewrite` 计算的结果写入到了 `aof_rewr ite_buf` 缓存中，然后当缓存中数据达到一定量后就会调用 `fsync()` 进行 **刷盘操作**，即 **数据同步** ，将数据写入到 **临时文件**。 该属性用于控制 `fsync()` 每次刷盘的数据量最大不超过 4MB 。这样可以避免由于单次刷盘量过大而引发**长时间阻塞**。

**(4) aof-load-turncated**

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

在进行 AOF 持久化过程中可能会出现 **系统突然宕机**的情况，此时写入到 AOF 文件中的最后一条数据可能会不完整。当主机启动后， Redis 在 AOF 文件不完整的情况下**是否可以启动**，取决于属性 `aof-load-truncated` 的设置。其值为：

*  `yes`： AOF 文件最后不完整的数据直接从 AOF 文件中截断删除，**不影响** Redis 的启动。
 *  `no` ：AOF 文件最后不完整的数据不可以被截断删除， Redis **无法启动**。

**(5) aof-timestamp-enabled**

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

该属性设置为 `yes` 则会开启在 AOF 文件中**增加时间戳的显示功能**，可方便按照时间对数据进行恢复。但该方式可能会与 当前AOF 解析器不兼容（以后可能会兼容），所以默认值为 `no` ，不开启。

**⭐️ 4.3.5、AOF持久化过程**

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

AOF **详细的持久化**过程如下:

1.  Redis 接收到的 **写操作命令** 并不是直接追加到磁盘的 AOF 文件的，而是将**每一条写命令** 按照 redis **通讯协议格式** 暂时 添加到 **AOF 缓冲区** `aof_buf` 。
2.  根据设置的**数据同步策略**，当同步条件满足时，再将缓冲区中的数据 **一次性写入磁盘**的 AOF 文件，以减少磁盘 IO 次数，提高性能。
3.  当磁盘的 AOF 文件大小达到了 `rewrite` 条件时， `redis-server` 主进程会 `fork` 出一个**子进程** `bgrewriteaof` ，由该子进程完成 `rewrite` 过程。
4.  **子进程** `bgrewriteaof` 首先对该磁盘 AOF 文件进行 `rewrite` 计算，将计算结果写入到一个**临时文件**，全部写入完毕后，再 `rename` 该**临时文件**为磁盘文件的**原名称**，覆盖原文件。
5.  如果在 `rewrite` 过程中又有**写操作命令追加**，那么这些数据会暂时写入 `aof_rewrite_buf` 缓冲区。等将全部 `rewrite` 计算结果写入**临时文件**后，会先将 `aof_rewrite_buf` 缓冲区中的数据写入**临时文件**，然后再 `rename` 为磁盘文件的**原名称**，覆盖原文件。

#### 4.4 RDB与AOF对比 ####

**⭐️ 4.4.1、RDB优势与不足**

**（1）RDB优势**

*  RDB **文件较小**
 *  数据**恢复较快**

**（2）RDB不足**

*  数据**安全性较差**
 *  **写时复制**会降低性能
 *  RDB 文件**可读性较差**

**⭐️ 4.4.2、AOF优势与不足**

**（1）AOF优势**

*  数据**安全性高**
 *  AOF 文件**可读性强**

**（2）AOF不足**

*  AOF **文件较大**
 *  **写操作**会影响性能
 *  数据**恢复较慢**

#### 4.5 持久化技术转型 ####

*  官方推荐使用 `RDB` 与 `AOF` **混合式持久化**。
 *  若对**数据安全性**要求不高，则推荐使用 **纯** `RDB` 持久化方式。
 *  不推荐使用**纯** `AOF` 持久化方式。
 *  若 Redis **仅用于缓存**，则无需使用任何持久化技术。

注：仅供学习参考，如有不足欢迎指正！

[MySQL _]: https://blog.csdn.net/weixin_43412762/article/details/132051493
[MySQL _ 1]: https://blog.csdn.net/weixin_43412762/article/details/132631240
[Redis]: https://blog.csdn.net/weixin_43412762/article/details/133688635
[Redis 1]: https://blog.csdn.net/weixin_43412762/article/details/133934585
[Redis 2]: https://blog.csdn.net/weixin_43412762/article/details/134104962
[5accbd3a4a1d45cc88764ab3e3bfccaa.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/1f9adce5fa1d44d497e51a8cda2fd3bf.png
[8561dff7d2f44bce90c0504d3bcf508f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/6467d5d5ab5d42c1b2353d243ab274ef.png
[98c18d3763314a33a90c3ba0cac660f2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/973bde0d6dc443cd9503cbcd4bf3a9a2.png
[b47c7510569e480c83b915be604ac489.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/be2bdac0caea42c7ba079145fd37b729.png
[ffd6c2e1d4d343209b6d304af9450c42.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/2b637d677b5a401bb60dc052a625770e.png
[1bd24f6bf11d43cc970b5f75b1ca875c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/df43eb0a964148768bfc2a9ecaef50ce.png
[f149d006f0eb4c32b735efcb3a2420d2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/d918df66cf1a46f8b2b5608b1e1e0ccb.png
[b9bd089f394f4e2a87147e54998f94d5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/64e936ac1e374b1db214938d9a62d982.png
[e99d2fa858374d858f0233422309ead4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/d725f0d698004399a0d0cf6d84c69823.png
[454275ea0cd84e43893bc513bb949dd6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/6dd49dc6fa4e410f8331b94dbf48f529.png
[2df7f23045bc43bbafe14bc2611d9ca9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/33b6d765d0c84f9080ca18844a3c795c.png
[4313be20a45744649be76e10bff11908.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/6de404d6afce44dba6798bcb9eccf9b5.png
[dba80f301e814f7889fc371e3bff1caf.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/9bbbf4c723254eaa8ea6ef3f51e82d66.png
[d962478715644992a3cda1c8d997e26e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/ac9d8fd4a09a4978873fd580c2e5d741.png
[d37656866a0c4b6b83a0536ddfd03b00.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/d645c0400bdf4605aa9bc668d72d5afb.png
[c1967603879d4d79a9d54ed2bd041b35.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/d79172eef08d4142ac425f2ddb89a255.png
[90690873a5954000b7daa6cf0153caa9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/2248dfa0d13b45b98689151801c9d32f.png
[66d39b53318440de84b80517f467f9d9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/d99e94d2fe57407aa9473d3afd2be0f0.png
[50766555d79248cd885539a798ac936b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/4640ff74843f4773b121e44967979669.png
[eeb0b002fa13422591994acb2990908c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/754953ddd21a45afb3332942429d431f.png
[a0d8d0bfe9d0495b9194a7b945bbe9e3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/da6939f623d6491c85617344cbcfddf5.png
[49e8471b41f7448bbb2879c53864b75b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/407346e90ce6430d9e178150f566a199.png
[aa984f69765f476baaea6352712c1e9f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/d39733c200c248e3bbd90429bc99f2bb.png
[d62507c07c804f5f8cfc0819b285149a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/add74f22e1b343b18dd26b445cb7dd25.png
[5a1209256a5e43e6870e3ef3b54ac0c7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/6f94b63ebe244df49408d0e2a6c6a5aa.png
[99f94dfbb99a4ec6962354d5b2dfacf5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/0c43b53464a34943822bae46d5d4d818.png
[9bd581f7d0f74a19a4a3440505866839.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/3e26f39f711b467f824f0791bec1dddf.png
[348f3416aff64ebdbf66f9455aba2cb1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/820bb3a6b1c4415e9216b6cc5fb9c0fb.png
[fb45900921bc4b61966429ac9f7d01dc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/935e85a76ee34490bfa3bb47c3c01e5a.png
[defcac2f35d2453f9583e49bf2771ccd.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/3349913874c441f9841f1427e2c9f0ba.png
[7cab2b1b42b6466daefe742f6e1a148e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/b033294239e04ba8adfe1d3ac3ced5f4.png
[2bbe5e78872348da9eeafb66b91fa397.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/f2e86c3852c042cb8b28c3c6892a0f79.png
[227a88f6885a4db7b58e6d6c9dd8bcc0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/f937610b7cc74ae88c60751b5882e59a.png
[6cfde1a8044a4289a65919f13ebc2d2d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/920e8ee50ebb45c6827085e5cda72b71.png
[b2044f68278e4189bd26e01c620238d7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/98619e0eab1f47eeaafdf2cb09a7afd0.png