一、RDB和AOF持久化机制的介绍

RDB是redis默认的持久化方案，在指定时间间隔内生成内存中数据的一份完整快照。即在指定目录下生成一个dump.rdb文件，Redis重启后会通过加载dump.rdb文件来恢复数据。

AOF机制对每条写入命令作为日志以append-only的模式写入一个日志文件中，当AOF文件大到一定程度的时候，AOF会进行rewrite操作。AOF rewrite操作会基于redis内存中的数据重写构造一个AOF文件，将原AOF文件删除。

如果同时使用RDB和AOF两种持久化机制，那么在redis重启的时候，会使用AOF来重新构建数据，因为AOF中的数据更加完整。

二、RDB详解

1.如何配置RDB持久化机制

通过配置 /etc/redis/redis.conf 

save <seconds> <changes> # save "" save 900 1 save 300 10 save 60 10000

解说：每隔<seconds>秒 超过<changes>个key发生了变更就生成一个新的dump.rdb文件。若不想用RDB方案，可以把 save "" 的注释打开。

2.RDB持久化机制的工作流程

  1. redis根据配置自己尝试去生成rdb快照文件。
  2. fork一个子进程出来。
  3. 子进程尝试将数据dump到临时的rdb快照文件中。
  4. 完成rdb快照文件的生成之后，就替换之前的旧的快照文件。

3.RDB持久化的优点

  1. RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备。
  2. RDB对redis对外提供的读写服务，影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可。
  3. 相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加快速。因为AOF存放的指令日志，做数据恢复的时候，要回放和执行所有的指令日志，来恢复出来内存中的所有数据。RDB就是一份数据文件，恢复的时候，直接加载到内存中即可。

4.RDB持久化的缺点

  1. 如果想要在redis故障时，尽可能少的丢失数据，那么RDB没有AOF好。一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦redis进程宕机，那么会丢失最近5分钟的数据。
  2. RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒或者甚至数秒，一般不要让RDB的间隔太长，否则每次生成的RDB文件太大了，对redis本身的性能可能会有影响。

三、AOF详解

1.如何配置AOF持久化机制

打开 redis.conf 文件，找到 append-only对应内容 redis 默认关闭，开启需要手动把no改为yes

appendonly yes

指定本地数据库文件名，默认值为 appendonly.aof

appendfilename "appendonly.aof"

指定更新日志条件

# appendfsync always
appendfsync everysec
# appendfsync no

解说： always：同步持久化，每次发生数据变化会立刻写入到磁盘中。性能较差当数据完整性比较好（慢，安全） everysec：出厂默认推荐，每秒异步记录一次（默认值） no：不同步

配置重写触发机制

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

解说：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。一般都设置为3G，64M太小了。

2.AOF持久化机制的工作流程

  1. redis fork一个子进程
  2. 子进程基于当前内存中的数据，构建日志，开始往一个新的临时的AOF文件中写入日志
  3. redis主进程，接收到client新的写操作之后，在内存中写入日志，同时新的日志也继续写入旧的AOF文件
  4. 子进程写完新的日志文件之后，redis主进程将内存中的新日志再次追加到新的AOF文件中
  5. 用新的日志文件替换掉旧的日志文件

3.AOF持久化机制的优点

  1. AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。
  2. AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复。
  3. AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite log的时候，会对其中的指导进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可。
  4. AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据。

4.AOF持久化机制的缺点

  1. 对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大。
  2. AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件。
  3. 唯一的比较大的缺点，其实就是做数据恢复的时候，会比较慢，还有做冷备，定期的备份，不太方便，可能要自己手写复杂的脚本去做。

四、RDB和AOF到底该如何选择

  1. 不要仅仅使用RDB，因为那样做数据恢复时丢失很多数据。
  2. 也不要仅仅使用AOF，因为那样有两个问题，第一，你通过AOF做冷备，没有RDB做冷备数据恢复的速度快; 第二，RDB每次简单粗暴生成数据快照，更加健壮，可以避免AOF这种复杂的备份和恢复机制的bug。
  3. 综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择; 用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复。