说说RDB和AOF

简介：

众所周知，redis是一个内存数据库，当机器重启后，内存中数据都会丢失。所以redis提供了两种持久化方式，即：RDB(保存一个时间点前的数据)和AOF(保存redis服务器端执行的每一条命令)。

RDB:

RDB有两种触发方式，

1. 其一为通过配置参数，例如在配置文件中写入如下配置：

   save 60 1000

   表示在60秒内有1000个key发生变化，就会触发一次RDB快照执行。
2. 通过客户端执行bgsave命令显示触发一次RDB快照，流程图如下：

RDB文件结构

由于RDB的键值保存形式不同，我们先对其文件结构进行介绍：

 

1. 固定字符串字段
2. RDB版本号
3. 辅助字段(使用每段前 opcodes来分辨是否为辅助字段)，可包含：
   1. 数据库号
   2. 当前数据库键值对散列表大小(加载时直接扩散到指定大小，加快速度)
   3. 当前数据库过期时间散列表大小
   4. Redis 具体键值对存储
   5. RDB文件结束标志
   6. 8字节校验码

键的保存形式

Redis中键都是字符串形式，所以存储方式如下：

LENGTH使用8字节保存了字符串长度。

值的保存形式

1. 列表保存：列表类型在Redis中为quicklist(双向链表连接起来的ZipList)结构，从整体来看是一个双向链表
2. 集合类型保存：集合类型在Redis有两种保存形式：intset，Hash。
   1. intset直接将intset按字符串保存，
   2. Hash则如下所示：
3. 有序集合类型的保存：ziplist，skiplist。
   1. ziplist直接将其整体作为一个字符串保存
   2. skiplist则如下：
4. 散列类型保存：ziplist，Hash。
   1. ziplist直接将其整体作为一个字符串保存
   2. Hash则如下：

AOF:

将Redis服务端执行过的每一条命令都保存到一个文件，这样当Redis重启时只要按顺序回访这些命令就会恢复到原始状态。

为什么有了RDB还需要AOF呢？

因为，RDB是一个时间点的快照，那么如果Redis发生故障，丢失的就是最后一次RDB开始到发生故障节点之间的数据，如果RDB数据越大，丢失越多。

综合来讲，RDB保存的是最终的数据，而AOF保存的是达到这个最终数据的状态。而且在加载过程中，RDB只需要把相应数据加载到内存并生成相应的数据结构，而AOF要创建一个伪客户端，将每条命令发给服务端，服务端在重写数据。

AOF执行流程

由于每条命令执行都要调用一个call函数，AOF就是在call函数里面实现的，流程如下图：

AOF文件写入

AOF持久化最终需要将缓冲区中的内容写入一个文件，写文件通过操作系统提供的write函数执行。但write之后的数据只是保存在kernel缓冲区中，真正写入磁盘还需要调用fsync函数。

AOF重写

由于需要控制AOF文件大小，所以出现相同命令会保留最终效果，举例说明：

比如我使用命令入下

set n1 a
set n1 b

最终aof留存的是 ("n1", "b")这个键值对.

AOF重写通过fork出一个子进程来执行，重写不会对原有文件进行任何修改和读取，子进程对所有数据库中所有的键各自生成一条相应的执行命令，最后将重写开始后父进程继续执行的命令进行回放，生成一个新的AOF文件

AOF重写触发方式：

1. 修改配置

   auto-aof-rewrite-percentage 64mb

2. 手动执行 bgrewriteaof 执行流程入下

先在父进程中将重写命令进行保存，然后再将这些命令再重写后的文件中进行回放

混合持久化

进行AOF重写时，子进程将当前时间点的数据块照保存为RDB文件格式，而后将父进程累积命令保存为AOF格式。

加载时会先判断是否以"REDIS"开头，即是否以RDB格式开头，是则按RDB格式加载，直到加载到AOF格式采用AOF加载