简介：
众所周知，redis是一个内存数据库，当机器重启后，内存中数据都会丢失。所以redis提供了两种持久化方式，即：RDB(保存一个时间点前的数据)和AOF(保存redis服务器端执行的每一条命令)。
RDB:
RDB有两种触发方式，
- 其一为通过配置参数，例如在配置文件中写入如下配置：
表示在60秒内有1000个key发生变化，就会触发一次RDB快照执行。save 60 1000 - 通过客户端执行bgsave命令显示触发一次RDB快照，流程图如下：
RDB文件结构
由于RDB的键值保存形式不同，我们先对其文件结构进行介绍：
- 固定字符串字段
- RDB版本号
- 辅助字段(使用每段前 opcodes来分辨是否为辅助字段)，可包含：
- 数据库号
- 当前数据库键值对散列表大小(加载时直接扩散到指定大小，加快速度)
- 当前数据库过期时间散列表大小
- Redis 具体键值对存储
- RDB文件结束标志
- 8字节校验码
键的保存形式
Redis中键都是字符串形式，所以存储方式如下：
LENGTH使用8字节保存了字符串长度。
值的保存形式
- 列表保存：列表类型在Redis中为quicklist(双向链表连接起来的ZipList)结构，从整体来看是一个双向链表
- 集合类型保存：集合类型在Redis有两种保存形式：intset，Hash。
- intset直接将intset按字符串保存，
- Hash则如下所示：
- 有序集合类型的保存：ziplist，skiplist。
- ziplist直接将其整体作为一个字符串保存
- skiplist则如下：
- 散列类型保存：ziplist，Hash。
- ziplist直接将其整体作为一个字符串保存
- 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重写触发方式：
- 修改配置
auto-aof-rewrite-percentage 64mb - 手动执行 bgrewriteaof 执行流程入下
先在父进程中将重写命令进行保存，然后再将这些命令再重写后的文件中进行回放
混合持久化
进行AOF重写时，子进程将当前时间点的数据块照保存为RDB文件格式，而后将父进程累积命令保存为AOF格式。
加载时会先判断是否以"REDIS"开头，即是否以RDB格式开头，是则按RDB格式加载，直到加载到AOF格式采用AOF加载
