众所周知，redis是一种内存数据库，在服务重启的时候内存中的数据会全部丢失，既然redis作为nosql的佼佼者，那肯定有自己的一套持久化方案来在宕机之后恢复自己的数据，那我们就来分析一波redis的持久化机制。
目前redis有两种持久化机制，第一种是RDB快照，这种方式直接把某个时间点的内存全量快照copy一份持久化到硬盘上，等服务重启后用来恢复的话不需要执行太多的命令就能把快照重写回内存；第二种是AOF日志，服务端每接收到一次写入命令，就会在执行完之后append到前一个日志后面，这样在磁盘上就会生成有序的指令队列，服务重启后，按序重新执行命令即可。
RDB快照
在满足RDB触发条件时（或者bgsave命令），redis会fork出一个子进程，由子进程全权负责内存快照的持久化工作。这个子进程和主进程共享一块代码段和数据段，当fork出子进程的时候，这块数据区域就几乎不会发生变化，随后子进程开始遍历数据并写入磁盘。
那这个时候，有新的写请求进来怎么办？
有学过java的小伙伴之前或多或少的接触过CopyOnWriteArrayList，之前将Hash数据结构那篇也讲过，都是利用CopyOnWrite机制来处理写请求的。首先redis将当前区域分成小块，如下：
当某一个page发现有写请求进来时，会把此page复制一份，在新的区域进行写操作，这也是redis在存储RDB时内存飙高的主要原因之一，不过redis中冷数据还是占绝大部分，所以page页复制的一般也不会很多。
AOF日志
Redis在有写命令进来时，会先进性合法性校验之后再执行，最后会把指令写入磁盘拼接到最近一条aof日志后面，恢复的时候顺序执行命令即可恢复。不过指令也并不是直接写入到磁盘当中的，磁盘页在内存有一个对应的缓存，aof日志是先写到这个缓存，再将缓存刷到磁盘当中，假如在刷到磁盘之前宕机，这个部分未写入磁盘的aof日志将会丢失。
Linux 的 fsync函数 可以强制将内核缓存刷到磁盘。Redis提供了3种 appendfsync 配置：
- always，每执行一条指令就fsync一次，这样完全放弃了redis的高性能换取持久性，一般没人这么玩。
- no，永不主动fsync，具体fsync操作交给操作系统，这样搞不是特别安全。
- everysec，定时fsync，一个折中方案，最好使用这种。
当aof日志越来越大的时候，主进程还会fork一个子进程对aof日志进行瘦身，就是将指令合并和重写，丢掉已经没有作用的指令，瘦身完成后，会拼接在瘦身的这段时间内新增的aof日志，替换掉老的的aof指令。
总结
也许，目前为止，你可能多多少少的对为什么会存在两种持久化机制有些想法了，这两种的持久化方式区别也是很明显的，存储速度方面，RDB快照是复制内存而AOF则是一点点拼接指令日志，相对而言肯定是“少取多拿”的AOF快一点；恢复速度方面，对于大数据集，粗略来讲RDB只需要做一次反序列化就可以了，而AOF则还需要执行一遍所有制令，那RDB恢复是要快一点；数据丢失方面，因为RDB是复制的整个内存信息，所以执行的肯定不会太频繁，一般会设定在一定时间范围key的修改次数达到一定数量才会触发，因此在下一次RDB之前不幸宕机，那 这段事件内的数据则会丢失，AOF因为每次拼接一小部分日志，速度很快，如果在redis命令执行完后到写入aof日志到磁盘这段时间内宕机，这只会丢失这一小部分数据，这两种方式都不能完全保证不丢失数据（fsync是以性能为代价强刷到磁盘，暂不讨论），一般在数据恢复的时候混合使用两种方式，RDB用来恢复较老的数据，AOF用来恢复剩下的刚刚修改过的数据。
