一、官网简介：
Redis 提供了不同级别的持久化方式：
RDB持久化方式能够在指定的时间间隔对你的数据进行快照存储。
AOF持久化方式每次对服务器的操作，当服务器重启的时候回重新执行这些命令来回复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使AOF的提交不至于过大。
如果你只希望你的数据在服务器运行的时候存在，你可以不适用任何持久化方式。
你也可以同时开启两种持久化，在这种情况下，当Redis重启时，它会优先使用AOF文件来还原数据集，因为AOF文件保存的数据通常比RDB文件保存的数据更加完整。
二、RDB
a. 快照
在默认情况下，Redis将数据库快照保存在名字为dump.rdb的二进制文件中。 你可以对Redis进行设置，让它在 “N 秒内数据集至少有M个改动” 这一条件被满足时， 自动保存一次数据集。 你也可以通过调用 SAVE 或者 BGSAVE ， 手动让 Redis 进行数据集保存操作。 比如说， 以下设置会让 Redis 在满足 “60秒内有至少有1000个键被改动” 这一条件时， 自动保存一次数据集： save 60 1000
这种持久化方式被称为快照（snapshot）
b. 快照的运行方式
当Redis需要保存dump.rdb文件时，服务器执行一下操作： 1.Redis调用fork()，同时拥有父进程和子进程。 2.子进程将数据集写入一个RDB文件中。 3.当子进程完成对新RDB文件的写入，Redis用新RDB文件替换原来的RDB文件，并删除旧的RDB文件。 这中方式使得Redis可以从写时复制（copy-on-write）机制中获益。
三、AOF
a. 只进行追加操作的文件（append-only file , AOF）
快照功能并不是非常耐久（durable）: 如果Redis因为某些原因而造成故障停机，那么服务器丢失最近写入、且未保存到快照中的那些数据。 尽管对于某些程序员来说，数据耐久性并不是最重要的考虑因素，但是那些追求完全耐久能力（full durability）的程序来说，快照功能就不太适用了。 从1.1版本开始，Redis增加了一种完全耐久的持久化方式：AOF持久化。 你可一通过修改配置文件来打开AOF功能： appendonly yes 从现在开始，每当Redisz执行一个改变数据集的命令时（比如set），这个命令就会被追加到AOF文件的末尾。 这样的话，当Redis重新启东时，程序就可以通过执行AOF文件的命令来达到重建数据及的目的
b. AOF 重写
因为AOF的运作方式是不断地将命令追加到文件的末尾，所以随着写入命令的不断增加，AOF文件的体积会变得越来越大。 举个例子，如果你对一个计数器调用了100次incr，那么仅仅是为了保存这个计数器的当前值，AOF文件就需要使用100条记录（entry）。 然而实际上，只是使用一条set命令已经足以保存计数器当前的值了，其余99条记录实际上是多余的。 为了处理这种情况，Redis支持一种有趣的特性：可以在不断服务客户端情况下，对AOF文件进行重建（rebuid）。 执行bgrewriteaof命令，Redis将生成一个新的AOF文件，这个文件包重建当前数据集所需的最最少命令。 Redis2.2需要自己手动执行bgrewriteaof命令；Redis2.4则可以自动触发AOF重写。
c. AOF 的耐久性如何？
你可以配置Redis多久才将数据fsync到磁盘一次。 有三个选项： ①：每次有新的命令追加到AOF文件是就执行一次fsync：非常慢，但是非常安全 ②：每秒执行一次：足够快（和使用RDB持久化差不多），并且在故障时只会丢失1秒钟的数据。 ③：从不fsync：将数据交给操作系统来处理。更快，但是非常不安全。 推荐（并且也是默认）的措施为每秒fsync一次，这种fsync策略可以兼顾速度和安全性。 总是fysns的策略在实际中非常慢，即时在Redis2.0对相关的的程序进行了改进之后仍然是如此 -- 频繁调用fsync 注定了这种策略不可能快的起来。
d. 如果AOF文件出错了怎么办
服务器可能在程序正在对AOF文件进行写入时停机，如果停机造成AOF文件出错（corrupt），那么Redis在重启的时候回拒绝载入这个AOF文件，从而确保数据的一致性不会被破坏。 当发生这种情况时，可以用以下方法来修复出错的AOF文件： 1.为现有的AOF文件创建备份。 2.使用Redis附带redis-check-aof程序，对原来的AOF文件进行修复。 修复命令：redis-check-aof --fix 3.(可选) 使用diff -u 对比修复后的AOF文件和原始AOF文件备份，查看两个文件之间的不同之处。 4.重启Redis服务器，等待服务器载入修复后的AOF文件，并进行数据的恢复。
e. AOF 的运作方式
AOF重写和RDB创建快照一样，都巧妙的利用了写是复制机制。 以下是AOF重写的执行步骤： 1.Redis执行fork()，现在同时拥有父线程和子线程。 2.子线程开始讲新AOF文件的内容写入到临时文件。 3.对于所有新执行的写入命令，父进程一边将他们累积到一个内存缓冲中，一边将这些改动追加到现在AOF文件的结尾：这样即使在重写的中途发生停机，现在的AOF文件也还是安全的。 4.当子进程完成重写工作时，他给父进程发送一个信号，父进程在接收到信号后，将内存缓冲缓冲中的所有数据追加到AOF文件的的末尾。 5.搞定！现在Redis原子的用新文件替换旧文件，之后所有命令都会直接追加到新AOF文件的末尾。
四、RDB 和 AOF 的优缺点
a. RDB 的优点
1.适合大规模的数据恢复 2.对数据完整性和一致性要求不高
b. RDB 的缺点
1.在一定间隔时间做一次备份，所以如果redis意外down掉的话，就 会丢失最后一次快照后的所有修改 2.fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
c. AOF 的优点
1. 每修改同步：appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好 2. 每秒同步：appendfsync everysec 异步操作，每秒记录 如果一秒内宕机，有数据丢失 3. 不同步：appendfsync no 从不同步
d. AOF 的缺点
1.相同的数据集而言，AOF文件远大于RDB文件，恢复速度慢于RDB 2.AOF运行效率要慢于RDB，每秒同步策略效率较好，不同步效率和RDB相同
五、RDB 和 AOF 我们应该用哪一个 ？
官网解释： 1.一般来说，如果想达到足以媲美PostgreSOL的数据安全性，你应该同时使用两种持久化功能。 2.如果你非常关心你的数据，但可以承受几分钟中的数据丢失，那么你可以只用RDB持久化。 3.有很多用户都只用AOF持久化，但是我们不推荐这种方式：因为定时生成RDB快照（snapshot）非常便于进行数据库备份，并且RDB回复数据的速度也要比AOF恢复的速度要快，除此之外，使用RDB还可以避免之前提到的AOF程序的bug。 因为以上提到的种种原因，未来我们可能将AOF和RDB整合成单个持久化模型。（这是一个长期计划。）
关注我的公众号，精彩内容不能错过