Redis持久化

持久化：

RDB：

RDB全称Redis Database Backup file(Redis数据备份文件)，也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。

生成RDB的方式有两种，一种是执行命令save（使用主进程生成RDB，这种方式会造成拥堵），另一种是bgsave（使用子进程生成RDB，一般使用这种方式），下面我们来讲一下使用bgsave生成RDB的流程和RDB的执行原理

当我们运行bgsave的时候，系统会开一个子进程（fork命令复制），然后复制一份页表给子进程（页表是什么呢？有点类似Java中的堆内存（堆内存存放地址指向栈内存），页表和存放数据的物理内存存在映射关系），这样子进程就可以对物理内存中的数据进行读操作来生成RDB，生成完后会使用新的RDB文件替换旧的RDB文件。但是这里有一个问题，如果子进程在生成RDB文件的时候，主进程要进行写操作怎么办呢？这里就要讲到fork采用的copy-on-write技术了。当主进程执行读操作的时候一切照常，但是一旦主进程要进行写操作，主进程就要把自己需要操作的数据（数据B）拷贝一份再进行写操作，并且在子进程完成任务之前，主进程想要对数据B进行读操作，就只会读自己复制出来的数据副本，而不会去读原本的数据B。

AOF：

AOF全称为Append Only File(追加文件)。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

AOF默认是关闭的，我们需要到配置文件（redis.conf）中打开

appendonly yes 

同时我们还可以指定刷盘策略

# 表示每执行一次写命令，立即记录到AOF文件（影响性能）
appendfsync always
#写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到A0F文件，是默认方案（最多会失去1s数据）
appendfsync everysec
#写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘（可能丢失大量数据）
appendfsync no

那我们想象一下，所有的命令都去保存，AOF文件的大小是小不了的，但是如果我们多次进行重复操作（比如多次添加），是不是可以用一条语句替代所有的呢？这里就要讲到bgrewriteaof命令了，通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。

二者差异：

数据完整性：RDB如果两次备份之间宕机，那没备份的数据就都没了，AOF则是根据你的刷盘策略（上面有讲）

数据恢复优先级：AOF毕竟可以指定频繁的刷盘，完整性肯定更高，优先级也更高