与时俱进，深入原理学习——Redis 4.0新持久化机制：混合持久化

Love The Way You Lie 2023-06-04 15:56 76阅读 0赞

众所周知，Redis是一个内存数据库。但它与其它内存数据库（如memcache）等有一个很大的区别，就是Redis可以持久化到磁盘。有了持久化方案，Redis就可以对数据进行备份、恢复、复制。

Redis提供了两种持久化方案：RDB和AOF。在Redis 4.0中，提供了一个新特性：两者的混合持久化。下面将介绍Redis的各种持久化方案的原理和配置。

使用**info persistence**命令可以查看当前所有有关持久化的信息：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ydWkzMTA_size_16_color_FFFFFF_t_70][]

RDB

原理

RDB持久化是通过快照方式来完成的。当达到触发条件时，Redis会自动将内存中所有数据以二进制方式生成一份副本并存储在硬盘上。

在配置文件可以配置当前配置的备份文件和目录，使用**config**命令也可以查看和设置：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ydWkzMTA_size_16_color_FFFFFF_t_70 1][]

触发条件

RDB分为主动触发和被动触发。

主动触发指的是客户端执行**save**和**bgsave**命令会进行持久化。

执行save会使Redis处于阻塞状态，不会响应任何其他客户端发来的请求，直到RDB快照文件执行完毕，需要谨慎使用。

bgsave即background save，后台保存。当执行bgsave命令时，Redis会**fork**出一个子进程来执行快照操作。需要注意的是，在fork子进程的过程中，Redis是阻塞的。而当子进程创建完成后，Redis就可以继续响应客户端的请求了。

子进程创建完成以后，返回“Background saving started”。子进程根据主进程的内存副本创建临时快照文件，当快照文件完成以后对原快照文件进行替换。替换完成后，子进程发送信号给主进程完成快照操作，主进程更新统计信息（info Persistence可查看），子进程退出。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ydWkzMTA_size_16_color_FFFFFF_t_70 2][]

被动触发有好几种情况，下面分别介绍一下。

save m n规则触发

在指定的m秒内，Redis中有n个键发生改变，则自动触发bgsave。该规则默认在redis.conf中进行了配置，并且可组合使用，满足其中一个规则，则触发bgsave

比如**save 900 1**，表明当900秒内至少有1个键发生改变时候，Redis会触发bgsave操作。

flushall触发

flushall命令用于清空数据库，请慎用，当我们使用了则表明我们需要对数据进行清空，那Redis当然需要对快照文件也进行清空，所以会触发bgsave。

shutdown触发

Redis在关闭前处于安全角度将所有数据全部保存下来，以便下次启动会恢复。可以使用客户端连入执行shutdown命令，也可以直接使用脚本关闭Redis，都会在退出前先执行save。

主从复制触发

在Redis主从复制中，从节点执行全量复制操作，主节点会执行bgsave命令，并将rdb文件发送给从节点。

数据恢复

当Redis意外崩溃或者关闭再次启动时，此时AOF持久化未开启时(默认未开启)，将使用RDB快照文件恢复数据。关掉Redis服务再重启，会发现日志里面有：

配置

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ydWkzMTA_size_16_color_FFFFFF_t_70 3][]

AOF

默认情况下，Redis是关闭了AOF持久化，开启AOF通过配置appendonly为yes开启，我们修改配置文件或者在命令行直接使用config set修改，在用config rewrite同步到配置文件。通过客户端修改好处是不用重启Redis，AOF持久化直接生效。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ydWkzMTA_size_16_color_FFFFFF_t_70 4][]

原理

如果说RDB相当于数据库的定时备份（冷备），那AOF就相当于数据库的热备。

通过前面的介绍会发现，如果使用RDB，在意外情况下，比如Redis服务突然宕机，这个时候有些内存里面的数据还没来得及刷新进磁盘，就会导致一部分数据丢失。

AOF就是用来解决这个问题的。AOF是Append Only File的缩写，AOF可以将Redis执行的每一条写命令追加到磁盘文件中，在Redis启动时候优先选择从AOF文件恢复数据。

因为每一次写操作，都需要记录到文件中，所以开启AOF持久化会对性能有一定的影响，但是大部分情况下这个影响是可以接受的，我们可以使用读写速率高的硬盘提高AOF性能。与RDB持久化相比，AOF持久化数据丢失更少，其消耗内存更少(RDB方式执行bgsve会有内存拷贝)。

AOF实现本质是基于Redis通讯协议，将命令以纯文本的方式写入到文件中。

redis协议：

首先Redis是以行来划分，每行以\\r\\n行结束。每一行都有一个消息头，消息头共分为5种分别如下:

**+**表示一个正确的状态信息，具体信息是当前行后面的字符。

**-**表示一个错误信息，具体信息是当前行后面的字符。

**\***表示消息体总共有多少行，不包括当前行,后面是具体的行数。

**$**表示下一行数据长度，不包括换行符长度\\r\\n,后面则是对应的长度的数据。

**:** 表示返回一个数值，后面是相应的数的字节符。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ydWkzMTA_size_16_color_FFFFFF_t_70 5][]

Redis AOF持久化过程

1 追加写入

Redis将每一条写命令以Redis通讯协议添加至缓冲区aof\_buf,这样的好处在于在大量写请求情况下，采用缓冲区暂存一部分命令随后根据策略一次性写入磁盘，这样可以减少磁盘的I/O次数，提高性能。

2 同步命令到硬盘

当写命令写入aof\_buf缓冲区后，Redis会将缓冲区的命令写入到文件，Redis提供了三种同步策略，由配置参数appendfsync决定，下面是每个策略所对应的含义：

no：不使用fsync方法同步，而是交给操作系统write函数去执行同步操作，在linux操作系统中大约每30秒刷一次缓冲。

always：表示每次有写操作都调用fsync方法强制内核将数据写入到aof文件。

everysec：数据将使用调用操作系统write写入文件，并使用fsync每秒一次从内核刷新到磁盘。这是折中的方案，兼顾性能和数据安全，所以Redis默认推荐使用该配置。

3 文件重写(bgrewriteaof)

当开启的AOF时，随着时间推移，AOF文件会越来越大,当然Redis也对AOF文件进行了优化，即触发AOF文件重写条件的时候，Redis将使用bgrewriteaof对AOF文件进行重写。这样的好处在于减少AOF文件大小，同时有利于数据的恢复。重写策略：

重复或无效的命令不写入文件

过期的数据不再写入文件

多条命令合并写入（当多个命令能合并一条命令时候会对其优化合并作为一个命令写入，例如“RPUSH list1 a; RPUSH list1 b" 合并为“RPUSH list1 a b” ）

重写

AOF文件重写过程与RDB快照bgsave工作过程有点相似，都是通过fork子进程，由子进程完成相应的操作，同样的在fork子进程简短的时间内，Redis是阻塞的，过程如图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ydWkzMTA_size_16_color_FFFFFF_t_70 6][]

过程说明：

1.开始bgrewriteaof，判断当前有没有bgsave命令(RDB持久化)/bgrewriteaof在执行，倘若有，则这些命令执行完成以后再执行。

2.主进程fork出子进程，在这一个短暂的时间内，redis是阻塞的。

3.主进程fork完子进程继续接受客户端请求，所有写命令依然写入AOF文件缓冲区并根据appendfsync策略同步到磁盘，保证原有AOF文件完整和正确。由于fork的子进程仅仅只共享主进程fork时的内存，因此Redis使用采用重写缓冲区(aof\_rewrite\_buf)机制保存fork之后的客户端的写请求，防止新AOF文件生成期间丢失这部分数据。此时，客户端的写请求不仅仅写入原来aof\_buf缓冲，还写入重写缓冲区(aof\_rewrite\_buf)。

4.子进程通过内存快照，按照命令重写策略写入到新的AOF文件。

4.1子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。

4.2主进程把aof\_rewrite\_buf中的数据写入到新的AOF文件。

5.使用新的AOF文件覆盖旧的AOF文件，标志AOF重写完成。

重写的触发条件：

AOF文件触发条件可分为手动触发和自动触发。

手动触发：客户端执行bgrewriteaof命令。

自动触发：自动触发通过以下两个配置协作生效：

auto-aof-rewrite-min-size: AOF文件最小重写大小，只有当AOF文件大小大于该值时候才可能重写，4.0默认配置64mb。

auto-aof-rewrite-percentage：当前AOF文件大小和最后一次重写后的大小之间的比率等于或者等于指定的增长百分比，如100代表当前AOF文件是上次重写的两倍时候才重写。

Redis开启在AOF功能开启的情况下，会维持以下三个变量

记录当前AOF文件大小的变量aof\_current\_size。

记录最后一次AOF重写之后，AOF文件大小的变量aof\_rewrite\_base\_size。

增长百分比变量aof\_rewrite\_perc。

每次当serverCron（服务器周期性操作函数）函数执行时，它会检查以下条件是否全部满足，如果全部满足的话，就触发自动的AOF重写操作：

没有BGSAVE命令（RDB持久化）/AOF持久化在执行；

没有BGREWRITEAOF在进行；

当前AOF文件大小要大于server.aof\_rewrite\_min\_size的值；

当前AOF文件大小和最后一次重写后的大小之间的比率等于或者大于指定的增长百分比（auto-aof-rewrite-percentage参数）

数据恢复

当AOF开启时候，Redis数据恢复优先选用AOF进行数据恢复。关掉Redis服务再重启，会发现日志里面有：

配置

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ydWkzMTA_size_16_color_FFFFFF_t_70 7][]

RDB与AOF对比

RDB的优点：

RDB文件体积小，因此在传输速度上较快，适合灾难恢复。RDB使Redis性能更高，子进程处理保存工作。在恢复大数据集时比AOF恢复速度快。

AOF的优点：

数据更完整和安全，秒级数据丢失（取决于appendfsync策略）。兼容性高，因为是基于Redis通讯协议形成的明文文件，所以容易阅读，且任何版本的Redis都兼容。

混合持久化

混合持久化是Redis 4.0才有的功能。

混合持久化同样也是通过bgrewriteaof完成的，不同的是当开启混合持久化时，fork出的子进程先将共享的内存副本以RDB方式写入AOF文件，然后在将重写缓冲区的增量命令以AOF方式写入到文件，写入完成后通知主进程更新统计信息，并将新的AOF文件替换旧的的AOF文件。

简单的说：新的AOF文件前半段是RDB格式的全量数据，后半段是AOF格式的增量数据。

数据恢复

使用混合持久化后，Redis依然优先加载AOF文件。可能有两种情况：

AOF文件开头是RDB的格式，先加载RDB部分的内容，再加载剩余的AOF

AOF文件开头不是RDB的格式，直接加载整个AOF文件

配置

4.0版本的混合持久化默认关闭的，通过**aof-use-rdb-preamble**配置参数控制，yes则表示开启，no表示禁用，默认是no，可通过**config set**修改。

混合模式可以结合AOF和RDB的优点，能够快速加载的同时避免丢失过多的数据。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ydWkzMTA_size_16_color_FFFFFF_t_70]: /images/20230601/d21fd84be24d4f9eb3d08eb6bf767deb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ydWkzMTA_size_16_color_FFFFFF_t_70 1]: /images/20230601/ffedffaee7704836b4de146e4fbd85a6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ydWkzMTA_size_16_color_FFFFFF_t_70 2]: /images/20230601/11cd6b256b024435aed26c1dbc925d41.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ydWkzMTA_size_16_color_FFFFFF_t_70 3]: /images/20230601/2db3d4de6684462889e650a8219c3cb9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ydWkzMTA_size_16_color_FFFFFF_t_70 4]: /images/20230601/39ad9781cd0545c7a2c8333ae8952f68.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ydWkzMTA_size_16_color_FFFFFF_t_70 5]: /images/20230601/5797ef5db13b4222a1dffd0e84d71610.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ydWkzMTA_size_16_color_FFFFFF_t_70 6]: /images/20230601/5f56c3de8cdf4aacae1355e4755a9977.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ydWkzMTA_size_16_color_FFFFFF_t_70 7]: /images/20230601/d769751f7cca45e2b337a9f13703c2bb.png