redis是内存中的数据库，数据存储在内存中，但我们都知道内存中的数据变化很快，很容易丢失。幸运的是Redis还分别为我们提供了持久化机制RDB(Redis DataBase)和AOF(Append Only File)。

让我们假设您已经知道redis基本语法，一个字母网站有很好的教程，可以看看。基本的文章不是写的，它们都是常见的命令。

下面我们来看看这两种方式。从浅到深。

1.持久化流程

既然redis数据可以存储在磁盘上，那么这个过程是什么样的呢？

有五个过程：

（1客户端向服务器发送写操作。(数据在客户的内存中。)。

（2数据库服务器接收写入请求的数据。(数据位于服务器端的内存中。)。

（3)服务器端呼叫write此系统调用将数据写入磁盘。(数据位于系统内存的缓冲区中。)。

（4操作系统将缓冲区中的数据传输到磁盘控制器。(数据在磁盘缓存中。)。

（5盘控制器将数据写入盘的物理介质。(数据真的落在了磁盘上。)。

这5这个过程在理想条件下是一个正常的保存过程，但在大多数情况下，我们的机器等会出现各种故障。以下是两种情况：

（1）Redis如果数据库失败，只要完成上面的第三步，就可以持久化和保存它。剩下的两个步骤将由操作系统为我们完成。

（2)操作系统故障，必须高于5所有步骤都可以完成。

这里只考虑保存过程中可能出现的故障。事实上，保存的数据也可能会被破坏，需要一定的恢复机制，但这里不会延长。现在主要考虑的是redis如何实现上述目标5保存磁盘的步骤。它提供了两个战略机制，即RDB和AOF。

二、RDB机制

RDB实际上，它是以快照的形式将数据保存在磁盘上。什么是快照？你可以理解为将当前时刻的数据保存到照片中。

RDB持久性是指在指定的时间间隔内将内存中的数据集的快照写入磁盘。它也是默认的持久化方法，即将内存中的数据作为快照写入二进制文件。,默认文件名为dump.rdb。

在我们安装了redis在那之后，所有的配置都在redis.conf在文件中，它被保存RDB和AOF这两种持久化机制的各种配置。

既然RDB机制是通过生成快照来保存某个时刻的所有数据，因此应该有一个触发机制来实现这一过程。为RDB提供了三种机制：save、bgsave、自动化。让我们单独来看看。

1、save触发方式

该命令会阻止当前Redis服务器，执行save在命令过程中，Redis不能处理任何其他命令RDB直到这一过程完成。具体流程如下：

转存失败 重新上传 取消

执行完成后，如果有一个旧的RDB文件中，用新的替换旧的。我们的客户可能有数万或数十万，这显然是不可取的。

2、bgsave触发方式

当执行该命令时，Redis快照操作在后台异步执行，快照也可以响应客户端请求。具体流程如下：

转存失败 重新上传 取消

具体操作如下Redis进程执行fork创建子进程的操作，RDB持久化流程由子流程负责，完成后自动结束。阻止仅发生在fork阶段，一般时间很短。基本上 Redis 内部全部RDB所有的手术都是采用的。 bgsave 命令。

3，自动触发

自动触发是由我们的配置文件完成的。在……里面redis.conf在配置文件中，我们可以设置以下配置：

①save：这里用于配置触发器。 Redis的 RDB 持久化条件，即何时将内存中的数据保存到硬盘。例如“save m n”。表示m数据集在几秒钟内就存在了。n当修改时，它会自动触发。bgsave。

默认配置如下：

表示900 秒，如果至少 1 个 key 将保存更改的值。save 900 1#表示300 秒，如果至少 10 个 key 将保存更改的值。save 300 10#表示60 秒，如果至少 10000 个 key 将保存更改的值。save 60 10000

不需要持之以恒，然后您可以注释掉所有内容。 save 行以禁用保存功能。

②stop-writes-on-bgsave-error ：缺省值为yes。启用时RDB上一次后台保存数据失败时，Redis是否停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上，否则没有人会注意到灾难(disaster)发生了。如果Redis重新启动，然后您可以再次开始接收数据

③rdbcompression ；缺省值为yes。对于存储到磁盘的快照，您可以设置是否压缩存储。

④rdbchecksum ：缺省值为yes。存储快照后，我们还可以制作redis使用CRC64算法进行数据验证，但这样做会增加近似10%性能消耗，如果想要获得最大的性能提升，可以关闭该功能。

⑤dbfilename ：设置快照的文件名，默认为 dump.rdb

⑥dir：设置快照文件的存储路径。此配置项必须是目录，而不是文件名。

我们可以修改这些配置以达到预期的效果。由于配置了第三种方法，因此我们对前两种方法进行比较：

转存失败 重新上传 取消

4、RDB 利害得失

①、优势

（1）RDB紧凑、完整的备份，非常适合备份和灾难恢复。

（2）生成RDB在备案时，redis主进程会fork()一个子进程来处理所有的保存工作，主进程不需要做任何磁盘。IO操作。

（3）RDB 恢复大型数据集时的速度比。 AOF 恢复速度更快。

②、劣势

RDB快照是存储二进制序列化形式的内存数据的完整备份，存储起来非常紧凑。执行快照持久化时，会打开一个专门用于快照持久化的子进程。子进程将拥有父进程的内存数据，父进程在修改内存子进程时不会做出反应。因此，在快照持久化过程中，修改后的数据不会被保存，可能会丢失数据。

三、AOF机制

完整备份总是很耗时，有时我们会提供一种更高效的方法。AOF，工作机制非常简单，redis将传递每个接收到的写命令。write函数被追加到文件中。普遍的理解是伐木。

1、持之以恒原则

他的原则是看以下数字：

转存失败 重新上传 取消

每当写入命令结束时，它都会直接保存在我们的AOF文件中。

2，文件重写原理

AOF这种方式还带来了另一个问题。持久文件变得越来越大。为了压缩aof永久文件。redis提供了bgrewriteaof指挥部。同时将内存中的数据作为命令保存到临时文件中。fork找出重写该文件的新进程。

转存失败 重新上传 取消

重写aof该文件的操作没有读取旧的aof文件，但将内存中的整个数据库内容作为命令重写。aof文件，这有点类似于快照。

3、AOF还有三种触发机制

（1)每次修改同步always同步持久化 每次数据更改都会立即记录到磁盘上。 性能较差，但数据完整性较好

（2)每秒同步everysec：异步操作，每秒记录。 如果在一秒内出现停机，则会丢失数据。

（3）不同no：从不同步

转存失败 重新上传 取消

4、优点

（1）AOF通常可以更好地保护数据不会丢失AOF会每隔1秒，通过后台线程执行一次。fsync手术，最大的损失1数据的秒数。(2）AOF日志文件没有任何磁盘寻址开销，写性能非常高，文件不易损坏。

（3）AOF即使日志文件太大，后台重写操作也不会影响客户端的读写。

（4）AOF日志文件的命令以非常易读的方式记录，这一功能非常适合灾难性误删除的紧急恢复。例如，有人不小心使用了它flushall该命令清空所有数据，只要这一次是后台rewrite它还没有发生，那么它可以立即复制。AOF文件，将是最后一个flushall删除该命令，然后AOF如果文件被放回，所有数据都可以通过恢复机制自动恢复。

5、缺点

（1)对于相同的数据，AOF日志文件通常更好RDB数据快照文件更大。

（2）AOF打开后，支持写入QPS会比RDB支持的写QPS低，因为AOF通常按每秒配置fsync一个日志文件，当然，每秒一次。fsync，性能还是很高的。

（3）以前AOF发生过bug，是通过了AOF恢复数据时，记录的日志没有恢复相同的数据。

四、RDB和AOF如何选择

如果你选择，最好是把这两者加在一起。因为你理解这两种持久化机制，剩下的就是看自己的需求，不同的需求选择不一定，但通常是组合使用。下面是一张要总结的图片：

对比这些特点，剩下的就是看看你自己。