Redis持久化

RDB持久化

  在指定的时间间隔内将内存中的数据集快照写入磁盘，它恢复时是将快照文件直接读到内存里。

执行方式

  Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

具体流程

  父线程fork一个子进程（fork过程中父进程阻塞），完成后由子进程完成持久化过程，父进程继续提供执行Redis其他命令。子进程将快照写到一个新的RDB文件中，完成后通知父进程进行替换。

save和besave：
  save 保存是阻塞主进程，客户端无法连接redis，等save完成后，主进程才开始工作，客户端可以连接

  bgsave 是fork一个save的子进程，在执行save过程中，不影响主进程，客户端可以正常链接redis，等子进程fork执行save完成后，通知主进程，子进程关闭。很明显bgsave 方式比较适合线上的维护操作。

AOF持久化

  以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来**(读操作不记录)， 只许追加文件但不可以改写文件**，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

AOF持久化流程

（1）客户端的请求写命令会被append追加到AOF缓冲区内；
（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；
（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的。

以上流程为图中未标黄部分。

黄色部分为AOF文件重写过程：
  为什么要重写：因为AOF是追加命令行的方式写入文件，文件会因此过大，重写是为了减小文件。
  过程：父进程fork出一个子进程（fork过程阻塞），子进程生成快照文件，其中rewrite_buf缓冲区是为了记录在生成快照期间执行的命令，保证AOF文件的实时性。  rewrite_buf写入的时机：子进程写完新的AOF文件后向主进程发出信号，主进程将rewrite_buf文件写入新的AOF文件，再替换文件。