RDB
rdb保存的是dump.rdb文件。
在指定的时间间隔内将内存中的数据快照写入磁盘，也就是行话中的快照，它恢复时是将快照文件直接读到内存。这个快照就是dump.rdb
Redis会单独创建（fork）一个子进程来进行持久化。
会先将数据写到一个临时文件中。待持久化过程都结束了，
在用这个文件替代上次持久化好的文件，
主进程是不任何的IO操作的，这就保持了很高的性能。
如果需要进行大规模的数据回复，且对数据恢复的完整性不是非常敏感，
那RDB方式要比AOF方式更加高效。
优势：
1、适合大规模的数据恢复
2、对数据完整性和一致性要求不高
劣势：
1、在一定间隔时间做一次备份，如果redis意味down掉的话，就会丢失最后一次快照后的所有修改
2、fork的时候，内存中的数据会被克隆一份，大致2倍的膨胀性需要考虑
AOF
AOF保存的是appendonly.aof文件
AOF的出现就是为了弥补RDB的劣势。
它以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来（读操作不记录），
只许追加文件但不可以修改文件，
redis启动之初会读取该文件重新构建数据。
优势：
每修改同步：appendfsnc always 同步持久化每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好。
每秒同步：appendfsnc everysec 异步操作，每秒记录，如果一秒内宕机，有数据丢失
不同步：appendfsnc no 从不同步
劣势：
1、相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
2、aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同
总结
RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储。
AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来回复原始数据，AOF命令以redis协议追加保存每次写的操作到文件末尾。
Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大
同时开启两种持久化方式：
在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,
因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。
那要不要只使用AOF呢？
Redis的作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，
快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。
