一杯茶的功夫，上手Redis持久化机制

虽然说RDB是一个压缩过的二进制文件，但是它的文件结构也需要有基本的了解，这样有助于我们理解其发挥的作用。如表格1所示，RDB文件由5个部分组成，按照从左到右的顺序依次是：

• 文件最开头是“REDIS”部分，其长度为5个字节，保存着“REDIS”五个字符。通过这五个字符，程序可以在载入文件时可以判断所载入的文件是否是RDB文件。

• 接下来是“db_version”长度为4字节，是一个字符串表示的整数，它记录了RDB文件的版本号，例如："0006"就代表RDB文件的版本为第六版。

• “databases”中可以包含着零个或任意多个数据库。

• “EOF”常量的长度为1字节，是 RDB文件正文结束的标识，当载入程序读取到个值的时，就意味着数据库的所有键值对都已经加载完毕了。

• “check_sum”是一个8字节长的无符号整数，保存着一个校验和。这个校验和是通过对“REDIS”、“db_version”、“databases”、以及“EOF”四个部分的内容进行计算得出的。Redis服务器在载入RDB文件时，会将载入数据所计算出的校验和与check_sum所记录的校验和进行对比，以此来判断RDB文件是否损坏。

在认识了RDB文件的结构以后，再来看看Redis 如何触发RDB持久化操作，以及其具体流程是如何的。这里包括三部分的内容，分别是save同步方式触发、bgsave 异步方式触发以及自动配置化的方式触发。

save同步方式触发RDB持久化

如图2所示，描述了save 同步方式持久化RDB的过程：

1. Redis Client端通过向Redis Server 发起save命令请求RDB持久化操作。

2. Redis Server接受到命令以后，将当前数据库快照保存到RDB文件中。

3. 由于save命令是同步操作，因此如果此时有其他Redis Client也向Redis Server发起save操作，会被阻塞直到第一个Redis Client完成save命令为止。

如图3所示，异步方式过程如下：

1. 依旧是Redis Client发起命令，不过命令改成了bgsave（background save有后台运行的意思），照旧请求Redis Server。

2. Redis Server接受到请求以后会fork出一个Redis子进程。

3. 这个子进程用来创建RDB文件。由于这个过程是异步的，因此Redis Server在启动子进程以后还可以接受其他请求。

4. Redis 子进程创建RDB文件以后会把成功的消息返回给Redis Server。

5. 由于bgsave命令是异步操作，如果此时有其他Redis Client同时请求Redis Server并不会被阻塞。Redis Server会响应请求，同样也会fork出对应的子进程进行RDB文件的创建。

如图4所示，这种方式可以理解为读取配置文件的方式。看下面的三个步骤：

1. Redis Server直接读取Redis 配置文件的内容，获取RDB持久化的信息。

2. 在Redis配置文件中配置了对应的save命令用来代替Redis Client请求的命令。其配置内容包括save命令、秒和修改次数。按照图中的例子来说，“save 500 3” 的意思是，在500秒的时间内如果Redis 数据库有3次修改就进行save请求，也就是请求RDB的持久化操作。

3. 一旦满足配置文件中的条件，Redis Server就会执行对应的save操作进行持久化。

图4 读取配置文件进行RDB持久化

一般而言Redis的配置信息会放到redis.conf配置文件中进行存储，其包含很多内容，这里我们就RDB持久化的部分给大家做简单介绍。redis.conf文件中找到“SNAPSHOTTING”（快照）的部分。看如下几个配置项：

上面提到了AOF持久化的过程就是日志不断追加的过程，这里通过图5 给大家介绍具体流程：

1. Redis Client作为命令的来源，会有多个源头以及源源不断的请求命令。

2. 在这些命令到达Redis Server 以后，并不是直接写入AOF文件，会将其这些命令先放入AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一片区域，存在的目的是当这些命令达到一定量以后再写入磁盘，避免频繁的磁盘IO操作。

3. AOF缓冲会根据对应的策略将命令写入磁盘上的AOF文件。

4. AOF文件随着写入文件内容的增加，会根据规则进行命令的合并，这里叫做AOF重写，从而起到AOF文件压缩的目的。

5. 当Redis Server 服务器重启的时候会从AOF文件载入数据。

上面提到了Redis 会将命令先写入到AOF缓冲区，再写入AOF文件。这里介绍一下AOF缓冲区同步文件的三个策略。

• always 策略：命令写入AOF缓冲区以后会调用系统fsync 操作同步到AOF文件，fsync完成后线程返回。这里的fsync是针对单个文件的操作，在进行磁盘同步的时候会阻塞直到写入磁盘完成以后返回，从而保证数据持久化的完成。

• everysec 策略：命令写入AOF缓冲区以后调用write操作，write完成后线程返回。此操作会有专门线程执行每秒执行一次。这里的write操作会触发延迟写（delayed write）机制，Linux 内核提供页缓冲区来提高硬盘IO性能。也就是说write 操作写入系统缓冲区以后就返回了，同步硬盘依赖于操作系统调度机制完成。（Redis默认配置）

• no策略：此种刷新策略是根据操作系统来决定的，也就是由操作系统来决定什么时候将缓冲区的数据写入到磁盘中。由于是操作系统来决定持久化，所以这种方式是不可控的。

AOF缓冲区会将Redis Client请求的命令源源不断地同步到AOF文件中，同时AOF文件会不断增大，这里就需要AOF重写。AOF重写就是把Redis进程内的数据转化为写命令同步到新的AOF文件的过程。其目的就是使重写后的AOF文件变得更小：

• 进程内已经超时的数据不会再写入AOF文件中。

• 旧AOF文件含有的无效命令，可以通过进程内的数据直接生成，新的AOF文件只保留最终的数据写入命令。例如就文件中存在三条命令，它们依次是“set hello A”、 “set hello B”和“set hello C”，对同一个key 进行负值只有最后一句“set hello C”是起效的，所以这三条命令会被“set hello C”一条命令替换，并且保存到新的AOF文件中。

• 另外，多条写命令可以合并成一个。例如依次存在三个命令：“lpush list A”、 “lpush list B”和“lpush list C”，这里就可以合并为一条命令“lpush list A B C”。

AOF重写不仅降低了文件的占用空间，同时更小的AOF也可以更快地被Redis加载。

说完了AOF重写的定义以后，下面来看看AOF重写的流程。一般而言有两种方式可以执行重写操作，分别是：bgrewriteaof 命令和AOF重写配置。

如图6 所示，整个执行过程由三步组成：

• Redis Client发起bgrewriteaof命令，这个命令是一个异步命令。由于Redis Server 在接受bgrewriteaof命令的同时，还可以接受其他Redis Client的命令，因此后面的第二步和第三步实际上是并行进行的。第二步：进行AOF重写，在同时第三步：还会接受其他非重写的命令请求。

• Redis Server接受到这个命令以后，会启动一个Redis的子进程用来执行AOF重写操作。这个重写过程实际上是针对Redis内存中的数据进行回溯，也就是下方红色区域的“AOF重写缓冲区”。

• 正如在第一步中提到的，在进行第二步的同时第三步还在接受客户端的请求并且通过“AOF缓冲区”保存到“旧AOF文件”中。

• 最终，完成AOF重写操作以后将“新AOF文件”写入到“旧AOF文件”中完成AOF重写。

通过上面的配置可以得到AOF重写的机制如下：

• 当AOF文件当前尺寸大于AOF重写的最小尺寸的时候就触发重写机制。通过上面配置来形成表达式就是：aof-current-size> auto-aof-rewrite-min-size

• 当AOF文件当前尺寸减去AOF文件本身尺寸的值除以AOF文件本身的尺寸得到的结果大于AOF文件重写比率的时候就需要出发重写机制。

  表达式就是：aof-current-size- aof-base-size/ aof-base-size > auto-aof-rewrite-percentage

由于Redis的配置文件中RDB是默认配置。AOF需要手动开启。

需要到Redis的配置文件redis.conf中进行如下设置。

#开启AOF模式 ，yes表示“开启AOF模式”。

appendonly yes