Tip:
一.RDB与AOF同时开启 默认先加载AOF的配置文件
二.相同数据集，AOF文件要远大于RDB文件，恢复速度慢于RDB
三.AOF运行效率慢于RDB,但是同步策略效率好，不同步效率和RDB相同
RDB的优点:
RDB是一个紧凑压缩的二进制文件，代表Redis在某一个时间点上的数据快照。非常适合用于备份，全量复制等场景。比如每6小时执行bgsave备份，并把RDB文件拷贝到远程机器或者文件系统中（如hdfs），用于灾难恢复。
Redis加载RDB恢复数据远远快于AOF方式。
RDB的缺点:
RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。
RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB笨笨，存在老版本Redis服务无法兼容新版RDB格式的问题。
AOF定义：以日志的形式记录每个操作，将Redis执行过的所有指令全部记录下来（读操作不记录），只许追加文件但不可以修改文件，Redis启动时会读取AOF配置文件重构数据
换句话说，就是Redis重启就会根据日志内容从头到尾执行一次来完成数据的恢复工作。
1.RDB持久化(以快照的方式) 策略（默认）：
save 900 1 （15分钟变更一次）
save 300 10 （5分钟变更10次）
save 60 10000 （1分钟变更1万次）
2.RDB默认配置文件名称：
dbfilename dump.rdb
3.表示是否开启AOF持久化：
appendonly yes(默认no,关闭)
4.AOF持久化配置文件的名称：
appendfilename "appendonly.aof"
5.AOF持久化策略(默认每秒)：
appendfsync always (同步持久化，每次发生数据变更会被立即记录到磁盘，性能差但数据完整性比较好)
appendfsync everysec (异步操作，每秒记录，如果一秒钟内宕机，有数据丢失)
appendfsync no （将缓存回写的策略交给系统，linux 默认是30秒将缓冲区的数据回写硬盘的）
6.AOF配置文件损坏修复方法：
进入redis安装路径 执行 redis-check-aof --fix AOF配置文件名称
7.AOF的Rewrite(重写) ：
定义：AOF采用文件追加的方式持久化数据，所以文件会越来越大，为了避免这种情况发生，增加了重写机制。
当AOF文件的大小超过了配置所设置的阙值时，Redis就会启动AOF文件压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof。
原理：当AOF增长过大时，会fork出一条新的进程将文件重写(也是先写临时文件最后rename)，遍历新进程的内存数据，每条记录有一条set语句。
重写AOF文件并没有操作旧的AOF文件，而是将整个内存中的数据内容用命令的方式重写了一个新的aof文件（有点类似快照）。
触发机制：Redis会记录上次重写时的AOF文件大小，默认配置时当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
auto-aof-rewrite-percentage 100 （一倍）
auto-aof-rewrite-min-size 64mb
8.RDB与AOF的选择：
做备份：当数据量大，且对恢复速度有要求，并且数据的一致性要求不高的话，可以只使用RDB
只做缓存：不用开启任何的持久化方式
两者都开启的建议：RDB数据不实时，同时使用两者时服务器只会找AOF文件，可不可以只使用AOF?建议不要，因为RDB更适合备份数据库(AOF在不断变化，不好备份)，快速重启，而且不会又AOF可能潜在的BUG,留作万一的手段。
来源：
https://www.cnblogs.com/wangfajun/p/5787077.html
http://www.chenxm.cc/post/526.html