###RDB方式的优点###
RDB是一个非常紧凑的文件,它保存了某个时间点的数据集,非常适用于数据集的备份,比如你可以在每个小时报保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题你也可以根据需求恢复到不同版本的数据集。
RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心，非常适用于灾难恢复。
RDB在保存 RDB文件时父进程唯一需要做的就是 fork出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他 IO操作，所以 RDB持久化方式可以最大化 Redis的性能。
与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些。
当 Redis需要保存 dump.rdb文件时， 服务器执行以下操作:
Redis调用forks.同时拥有父进程和子进程。
子进程将数据集写入到一个临时 RDB文件中。
当子进程完成对新 RDB文件的写入时，Redis用新 RDB文件替换原来的 RDB文件，并删除旧的 RDB文件。
这种工作方式使得 Redis可以从写时复制（copy-on-write）机制中获益。
###AOF方式的优点###
使用AOF会让你的Redis更加耐久:
你可以使用不同的 fsync策略：无 fsync、每秒 fsync、每次写的时候 fsync .使用默认的每秒 fsync策略, Redis的性能依然很好( fsync是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障，你最多丢失1秒的数据。
AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令,你也也可使用redis-check-aof工具修复这些问题。
Redis可以在 AOF文件体积变得过大时，自动地在后台对 AOF进行重写： 重写后的新 AOF文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis在创建新 AOF文件的过程中，会继续将命令追加到现有的 AOF文件里面，即使重写过程中发生停机，现有的 AOF文件也不会丢失。 而一旦新 AOF文件创建完毕，Redis就会从旧 AOF文件切换到新 AOF文件，并开始对新 AOF文件进行追加操作。
AOF文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis协议的格式保存， 因此 AOF文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL命令， 但只要 AOF文件未被重写， 那么只要停止服务器， 移除 AOF文件末尾的 FLUSHALL命令， 并重启 Redis， 就可以将数据集恢复到 FLUSHALL执行之前的状态。
###save和 bgsave保存###
有的，Redis提供了save和bgsave这两种不同的保存方式,并且这两个方式在执行的时候都会调用rdbSave函数，但它们调用的方式各有不同：
save直接调用 rdbSave方法 ，阻塞 Redis主进程，直到保存完成为止。在主进程阻塞期间，服务器不能处理客户端的任何请求。
bgsave则 fork出一个子进程，子进程负责调用 rdbSave，并在保存完成之后向主进程发送信号，通知保存已完成。因为 rdbSave在子进程被调用，所以 Redis服务器在 bgsave执行期间仍然可以继续处理客户端的请求。
save是同步操作，bgsave是异步操作。
bgsave命令的使用方法和save命令的使用方法是一样的：
RDB持久化 默认开启
关闭持久化
save ""
主动保存
save同步
bgsave异步
AOF持久化 默认关闭
手动开启
appendonly yes
持久化方式配置
appendfsync always #每次有数据修改发生时都会写入AOF文件（安全但是费时）。
appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync no #从不同步。高效但是数据不会被持久化。
自定义AOF文件
appendfilename "appendonly.aof"
选择方式
分析对比两种方式并做了测试后，发现这是两种不同风格的持久化方式，那么应该如何选择呢？
对于企业级的中大型应用，如果不想牺牲数据完整性但是又希望保持高效率，那么你应该同时使用 RDB和 AOF两种方式；
如果你不打算耗费精力在这个地方，只需要保证数据完整性，那么优先考虑使用 AOF方式；
RDB方式非常适合大规模的数据恢复，如果业务对数据完整性和一致性要求不高，RDB是很好的选择
