(Redis) RDB与AOP持久化的实现与本质区别

Redis服务器

Redis是一个键值对数据库服务器，服务器中通常包含着任意个非空数据库，而每个非空数据库中又可以包含任意个键值对，我们将服务器中的非空数据库以及它们的键值对统称为数据库状态。

例如，下图就是一个包含三个数据库以及数据控中的键值对的服务器的数据库状态。

Redis是内存数据库，它将自己的数据库状态存在内存中，所以如果不想办法将存储在内存中的数据库状态保存在磁盘中，那么一旦服务器进程退出，服务器中的数据库状态也会消失不见。

RDB持久化

Redis提供了RDB持久化功能，可以将Redis内存中的数据库状态保存在磁盘中，避免数据意外丢失。该功能可以将某个时间点上的数据库状态保存在一个经过压缩的二进制RDB文件中，之后通过该文件，我们还可以还原生成RDB文件时的数据库状态。

RDB文件的创建

有两个Redis命令可以用于生成RDB文件，一个是SAVE，另一个是BGSAVE，他们的的区别是：

• SAVE命令会阻塞Redis服务器进程（Redis服务是单线程的），直到RDB文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求，客户端发送的所有请求都会被拒绝。
• BGSAVW命令会派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程（父进程）可以继续处理客户端发来的命令请求。

自动间隔性保存

因为BGSAVE命令可以在不阻塞服务器进程的情况下执行，所以Redis允许用户通过设置服务器配置的save选项，让服务器每隔一段时间自动执行一次BGSAVE命令。

用户可以设置多个save选项，只要其中任意一个条件被满足，服务器都会执行BGSAVE命令。Redis配置文件中的默认配置为：

官方给出的说明是，只要满足以下三个条件中的一个，BGSAVE就会执行：

• 服务器在900秒之内，对数据库进行了至少1次修改。
• 服务器在300秒之内，对数据库进行了至少10次修改。
• 服务器在60秒之内，对数据库进行了至少10000次修改。

咋一看，这个说明让人无法理解到底Redis是如何判断某一条件是否成立了。比如：900秒之内的时间是从什么时候开始计算的？ 修改次数的计数又是如何选取区间的呢？

接下来，我们就来看看Redis底层到底是如何实现和判断的。

在Redis启动后，save配置选项的值会被保存在 redisServer结构中的saveparams数组中，数组中的每一个元素就是一个save条件。我们以上面列出的默认save配置为例，热门服务器中的saveparams数组就是这个样子的：

除了saveparams数组外，服务器还会维持着一个dirty计数器和一个lastsave属性

• dirty计数器记录距离上一次成功执行SAVE或BGSAVE命令之后服务器对数据库状态（服务器中所有数据库）进行了多少次的修改（写入，删除，更新等）。
• lastsave是一个UNIX时间戳，记录了上次成功执行SAVE或BGSAVE命令的时间点。

Redis服务器周期性的执行serverCron函数，默认每隔100毫秒就会执行一次，该函数其中一项工作就是检查save选项所设置的保存条件是否满足，如果满足的话就会执行BGSAVE命令。伪代码如下：

由伪代码可知，判断某一条件是否满足，就是判断数据库状态修改的次数是否大于等于条件中的changes，并且判断时间间隔是否大于seconds。
例如，当我们在55秒内进行了10000次修改，那么在第60秒才会执行BGSAVE；当我们在66秒内进行了10000次修改，那么在66秒时就会执行BGSAVE。

RDB小结

Redis使用RDB的方式进行持久化时，当数据库中的数据很多时，一次性保存所有的数据会花费较长的时间，可能有花费几分钟。由上面分析可得，两次RDB持久化之间的最小时间间隔为 ：60s + 执行一次BGSAVE所需要的时间。 所以使用RDB的持久化方式时，保存数据的粒度较大，会存在较多的数据的丢失。例如在进行BGSAVE时停电了，那么在这两个BGSAVE之间进行的所有修改信息都会丢失。

AOF持久化

除了RDB外，Redis还提供了AOF(Append Only File) 持久化功能。与RDB通过保存数据库中的键值对来记录数据库状态不同，AOF是通过保存Redis服务器所执行的修改命令来记录数据库状态的。

AOF持久化功能的实现可以分为命令追加，文件写入和文件同步三个步骤。

• 命令追加：服务器在执行完一个修改命令后，会以协议格式将被执行的命令追加到服务器的aof_buf缓冲区的末尾。
• 文件写入：将aof_buf中的数据保存在AOF文件中（操作系统的内存缓冲区）。为了提高文件的写入效率，在现代操作系统中，当用户调用write函数，将一些数据写入文件时，操作系统会将写入数据暂时保存在一个内存缓冲区中，等到缓冲区的空间满了，或者超过了指定的时限之后，才真正将缓冲区中的数据写入磁盘中。
• 文件同步：将AOF文件(操作系统缓冲区)中的数据写入磁盘。

根据Redis配置文件中的 appendfsync 值，Redis服务器会在指定的时刻进行文件同步。

AOF重写

因为AOF是通过保存被执行的修改命令来记录数据库状态的，所以随着服务器的运行，AOF文件的内容就会越来越多，体积越来越大。不加以控制的话，体积过大的AOF文件可能会对Redis服务器造成影响，并且AOF文件的体积越大，进行数据还原所需的时间就越多。所以我们需要解决AOF文件膨胀的问题，Redis为我们提供了AOF文件重写功能。

虽然Redis将生成新AOF文件替换旧的AOF文件的功能叫做“AOF文件重写”，但是实际上，AOF文件重写并不需要对现有的AOF文件进行任何读取、分析和写入操作，这个功能是通过读取服务器当前的数据库状态来实现的。

例如，开启Redis后，我们执行了下面的操作：

所以在现有的AOF文件中，为了记录这个list，AOF文件中就保证了6条命令。当其实这个list的数据只用一条
命名就能代替现有的6条命令了，所以在AOF重写时就只需要保存一条命令，从而大大减少了AOF文件的体积。

AOF小结

由上文可以，AOF持久化是通过保存服务器执行的修改命令来保存数据库状态的。相比于RDB,AOF方式的保存粒度更加小，当我们将appendfsync设置为 always时，我们最多会丢失一条修改的命令，当这是为evertsec时，我们最多会丢失1秒的修改数据。