redis的持久化机制有两种，AOF和RDB。redis默认开启rdb，先说一下RDB，redis提供了两个命令来生成RDB文件，save和bgsave，他们的区别在于是否要fork一个子进程来执行。使用的话，可以配置多长时间执行bgsave或者是配置多长时间内，修改了几次那就执行bgsave。还要注意一下，rbd执行的是全量快照，也就是每次都是把内存中的数据加载到硬盘中，所以不能配置的太频繁，会有性能问题。这也导致了rdb相对来说丢失的数据会更多一些。 （ 还有一个点就是rdb交给子进程来进行复制，那主进程还能写入吗？可以的，这里采用了写时复制的方法，即fork子进程后，子进程会复制主进程的一份页表，但是这两份页表指向的是同一块物理内存，只有发生修改内存的情况时，物理内存才会复制修改的部分，子进程对应的物理内存还是原来那部分。) AOF的话默认是没有开启的，可以配置后开启。aof只会记录写操作，读操作是不会记录的，而且写操作的执行和写日志的过程是一个同步的过程，先执行写操作，执行完后再写日志。这样的话，对写入日志的策略配置就比较重要了，不然写日志阻塞了，之后命令的执行也会阻塞住。aof写进硬盘的策略有三种，always，everysec，no，always的话就是每一个写操作执行完，就同步将aof日志数据写进硬盘，everysec就是每次写操作执行完后，先将命令写入到aof文件的内核缓冲区（page cache：文件的高速缓冲区，在内存中，当读取时直接在这里读），然后每隔一秒将缓冲区里的内容写回硬盘，no意味着每次执行写操作命令将命令写入到aof文件的内核缓冲区，再又操作系统决定何时将缓冲区内容写回硬盘。嗯。。还有就是aof文件是不断增大的，当这个文件大小达到所设定的阈值，redis就启用aof重写机制（bgrewriteaof），将对每一个键值的操作合并成一条命令，嗯。。大概就这样。

    使用的话，一般都是两个都开，RDB恢复数据很快，但是数据不全，aof数据比较全，但是它的恢复比较慢，在redis4.0时，支持了两种混合使用，即aof文件的前半部分是rdb格式的全量数据，后面是aof的增量数据。