redis之持久化

    redis是内存级的服务器，一旦重启内存数据将会丢失，为了在重启时能数据恢复，则需要实时的将内存中的数据持久化到硬盘上。

redis第一版持久化（RDB 全量同步）

       redis的第一个版本0.091就有持久化了，并且借助了Linux的cow（copy on write）特性生成内存数据快照，将后将快照数据序列化到硬盘上。

当在修改请求量很大的情况下，在持久化过程中服务器重启，将导致大量的数据丢失。

在系统资源一般的请求下，fork也会是一个性能消耗，将阻塞主进程的提供服务。

redis第二版持久化（AOF 增量同步）

    在redis1.1.90中引入了AOF。AOF(Append Only File) 将每一个有修改数据的命令追加到日志文件中，在重启时将加载出来一条一条的执行以恢复数据（命令重放）。

    因为是写文件IO，其实并非直接写入到硬盘上，write只是将其拷贝到了内核的缓冲区中，等待刷新到硬盘上。所以有了一个刷新磁盘的策略

• appendfsync always

      每写一条日志都调用fdatasync, 这个也是最安全的，数据丢失的最少，但是性能有影响

• appendfsync everysec

     每秒钟调用一次fdatasync, 这样数据可能丢失1秒钟，并且性能影响不大

• appendfsync no

     不主动调用fdatasync，由操作系统自己调度，一般是30秒，数据可能丢失的更多

AOF生成流程

AOF加载过程

随着时间的推移，AOF文件将越来越大，存储是一个问题；并且重启时，耗费更长的时间，因此需要对AOF文件进行瘦身（重写）。同样是通过fork生成快照进行操作，并且在重写的过程中，也同时在写原先的AOF文件（双写），防止异常。

redis第三版持久化（RDB + AOF 混合）

       在redis4.0.0中引入了混合持久化的方式,AOF文件的开头是RDB内容，后续是AOF内容，这样即加快了在重启时的恢复速度，也减少了数据的丢失。

       其实刚开始的时候文件中只有AOF内容，当在重写AOF文件时，将先进行RDB，然后将新的AOF内容追加到RDB文件后面。

以下为aof重写过程