Redis之数据持久化

Redis有两种数据库持久化方案：RDB和AOF

RDB：

Redis DataBase 的缩写，中文名为快照/内存快照，RDB持久化是把当前进程数据生成快照保存到磁盘上的过程，由于是某一时刻的快照，那么快照中的值要早于或者等于内存中的值。
Redis工作在内存中，rdb就是每隔一段时间，对内存中的数据做一次快照，保存在RDB文件中。而且Redis的主从同步可以实现异步，也是由于RDB的机制，它在做快照时会fork出一个子进程，由子进程来做快照，父进程完全处理请求，毫不影响，很适合数据的备份。
缺点：如果数据量很大的话，RDB它要保存一个完整的数据集，是一个很大的工作，如果时间间隔设置的太短，那么严重影响Redis的性能，但是按照常规设置的话，例如5分钟一次，那么如果宕机或者重启就会基于上次做RDB的时间从而丢失分钟级别的数据。

具体流程如下：

1. redis客户端执行bgsave命令或者自动触发bgsave命令；
2. 主进程判断当前是否已经存在正在执行的子进程，如果存在，那么主进程直接返回；
3. 如果不存在正在执行的子进程，那么就fork一个新的子进程进行持久化数据，fork过程是阻塞的，fork操作完成后主进程即可执行其他操作；
4. 子进程先将数据写入到临时的rdb文件中，待快照数据写入完成后再原子替换旧的rdb文件；
5. 同时发送信号给主进程，通知主进程rdb持久化完成，主进程更新相关的统计信息（info Persitence下的rdb_*相关选项）。

AOF：

1，Redis是“写后”日志，Redis先执行命令，把数据写入内存，然后才记录日志。日志里记录的是Redis收到的每一条命令，这些命令是以文本形式保存
2，AOF就像MySQL库中的binlog一样，把每一次写操作以追加的形式记录在其中以文件的形式刷到磁盘里。默认使用fsync策略，Redis的性能依然很好（fsyhc是由后台线程进行处理的，主线程会尽力处理客户端请求），一旦出现故障，最多丢失1秒的数据。

缺点：AOF文件的大小会随着时间线增大，一段时间后就会变得很大；如果要在一端以AOF的形式来恢复数据，那么由于AOF文件的巨大体积，可能会让进程卡住，非常的慢。

如何实现AOF

AOF日志记录Redis的每个写命令，步骤分为：命令追加（append）、文件写入（write）和文件同步（sync）。

1. 命令追加 当AOF持久化功能打开了，服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器的 aof_buf 缓冲区。
2. 文件写入和同步 关于何时将 aof_buf 缓冲区的内容写入AOF文件中,

RDB和AOF混合方式（4.0版本)

Redis 4.0 中提出了一个混合使用 AOF 日志和内存快照的方法。简单来说，内存快照以一定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作。

从持久化中恢复数据

1. redis重启时判断是否开启aof，如果开启了aof，那么就优先加载aof文件；
2. 如果aof存在，那么就去加载aof文件，加载成功的话redis重启成功，如果aof文件加载失败，那么会打印日志表示启动失败，此时可以去修复aof文件后重新启动；
3. 若aof文件不存在，那么redis就会转而去加载rdb文件，如果rdb文件不存在，redis直接启动成功；
4. 如果rdb文件存在就会去加载rdb文件恢复数据，如加载失败则打印日志提示启动失败，如加载成功，那么redis重启成功，且使用rdb文件恢复数据；

那么为什么会优先加载AOF呢？因为AOF保存的数据更完整，通过上面的分析我们知道AOF基本上最多损失1s的数据。

参考链接：Redis持久化:RDB和AOF机制详解