Redis持久化主要有两种实现方式，一种是AOF日志，一种是RDB快照。
AOF就是记录下来数据的变化。
RDB就是相当于拍个照记录下来当前所有的数据。
RDB由于记录的是全量数据，会导致出现数据的同步并不快。RDB有两种数据同步方式，一种是save,一种是bgsave，save同步的话，会直接阻塞我们的主线程。这是非常要命的，除非我们打算要关闭redis服务不然这么做会造成请求全部阻塞。当然redis在关闭时也默认会使用save，这倒是不用我们开发人员操作。那么还有一种就是后台现成的保存。redis如何进行后台更新的，这时候我们就知道有一个叫写时复制。这时候会创建一个子进程。为什么不直接创建一个线程进行复制。首先RDB数据很大，我们不可能直接线程拷贝一份完成的。那么一定会有数据是共享内存的。这时候多线程就会导致不安全。但是如果我们创建子进程进行的就是写时复制。写什么就会拷贝一份，然后再写，就不会对原有的数据造成影响。这时候也会有一个问题就是如果老倒霉蛋出现了所有的数据都更新了，那么所有的数据都被复制了一份，导致Redis内存翻了一倍。我们可以设置合理的触发RDB机制，比如多少秒内更新了多少就刷一次。
相比之下AOF就不像RDB那样子非常的鲁莽，直接记录我们数据的变更。会将命令追在文件中写入。通过命令进行恢复。AOF相比之下恢复起来就比RDB慢了不少。AOF会将命令写入到aof的缓冲区，和mysql的日志写入非常像，我们写入到缓存然后调用系统函数写入内核缓冲区，然后由内核发起操作调用IO写入到硬盘。值得一提的是AOF还有一个重写操作，比如我们对同一个数据进行了多次修改，这不就意味着我们写入的时候多次操作没啥意义，只有最后一次有效，这时候怎么办呢？AOF为了解决这个问题，提出了重写，我们会对磁盘进行重写。如果重写过程中，出现了新的AOF文件写入那咋办，这时候写时复制这种操作又来了。我们还可以进行混合持久化，就是重写的时候干脆直接写成RDB这样子。
AOF的写回时机有三种。
- Always，这个单词的意思是「总是」，所以它的意思是每次写操作命令执行完后，同步将 AOF 日志数据写回硬盘；
- Everysec，这个单词的意思是「每秒」，所以它的意思是每次写操作命令执行完后，先将命令写入到 AOF 文件的内核缓冲区，然后每隔一秒将缓冲区里的内容写回到硬盘；
- No，意味着不由 Redis 控制写回硬盘的时机，转交给操作系统控制写回的时机，也就是每次写操作命令执行完后，先将命令写入到 AOF 文件的内核缓冲区，再由操作系统决定何时将缓冲区内容写回硬盘。
接下来我们详细说说AOF的重写机制，通过fork一份页表我们进行了写时复制，这时候我们的子进程不断读取可以重写的部分，然后进行重写。这时候有数据进来我们就写时复制一份，然后往AOF缓存里也追加命令。这样子就避免了阻塞和期间的数据丢失问题啦。
