RDB
优点
1.rdb会生成多个数据文件，每个数据文件代表了某一个时刻中redis的数据，这种多个数据文件的方式，每个文件都代表了某一个时刻的完整数据快照，非常适合做冷备。
2.rdb对redis对外提供读写服务，影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行对RDB持久化即可。
3.相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加快速。
缺点
1.如果想要在redis故障时，尽可能少的丢失数据，那么RDB没有AOF好，一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦redis进程宕机，那么会丢失最近5分钟的数据，这个问题，就是rdb更大的缺点，就是不合适做第一优先的恢复方案，如果你依赖RDB做第一优先恢复方案，会导致数据丢失的比较多。
2.RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户提供的服务暂停数毫秒，或者数秒。一般不要让RDB的间隔时间太长，否则每次生成的RDB文件太大，对redis本身的性能可能也会有影响。
配置
1.save 60 1000: 每隔60s，如果有超过1000个key发生了变更，那么就生成一个新的dump.rdb文件，就是当新的redis内存中完整数据快照。这个操作称为snapshotting, 快照。也可以手动调用save或者bgsave命令，同步或者异步执行rdb快照生成，save可以设置为多个，就是多个snapshotting的检查点。每到一个检查点，就会check一下，是否有指定key数量发生了变更，如果有，就生成一个新的dump.rdb文件
工作流程
1.redis根据配置尝试自己生成一个rdb快照文件。
2.fork一个子进程出来
3.子进程尝试将数据dump到临时的rdb快照文件中
4.完成rdb快照文件生成之后，就替换之前旧的快照文件dump.rdb，每次生成一个新的快照，就会覆盖之前的老快照，dump.rdb只有一个
模拟实验
通过redis-cli shutdown这种方式去停掉redis，其实是一种安全退出的模式，redis在退出的时候，会将内存中数据立即生成一个完整的rdb快照。
用kill -9 粗暴杀死redis进程，模拟redis异常退出，导致内存数据丢失的场景，这次就发现，redis进程被杀掉，数据没有进dump文件，几条最新的数据丢失了。
AOF
优点
1，AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次sync操作，最多丢失1秒中的数据，每隔1秒，就执行一次sync操作，保证os cache中的数据写入磁盘，redis进程挂了，最多丢掉1秒中数据。
2.AOF日志文件中以Apend-only模式写入，所以没有任何磁盘寻址的开销，写入的性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复。
3.AOF日志文件即使过大的时候，也会出现后台重写操作，也不会影响客户端的读写，因为在rewrite log的时候，会对其中的指令进行压缩，创建出一份需要恢复数据数据的最小日志来。再创建新日志文件的时候，老的日志还是照常写入。当新的merge日志文件ready的时候，再交换老日志文件即可。
4.AOF日志文件的命令通过非常可读的方式记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清除了所有的数据，只要这个时候后台rewrite还没有发生，那么立刻拷贝AOF文件，将最后一条flushall命令给删除，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据。
缺点
1.对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大。
2.AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒同步一次日志文件，当然，每秒一次同步，性能还是很高的，如果你要保证一条数据都不丢，也是可以的，AOF的同步设置每写入一条数据，同步一次，那样redis QPS大降
3.做数据恢复的时候，会比较慢，还有做冷备，定期备份，不太方便，可能要自己手写复杂的脚本去做，做冷备不合适。
配置
1.AOF持久化，默认是关闭的，默认是打开RDB持久化，appendonly yes，可以打开AOF持久化机制，在生产环境里面，一般来说AOF都是要打开的，除非你说随便丢个几分钟的数据也无所谓，打开AOF机制后，redis每次收到一条写命令，就会写入日志文件中，当然是先写入os cache的，然后每隔一定时间再同步一下。
2.即使AOF和RDB都开启了，redis重启的时候，也是优先通过AOF进行数据恢复的，因为AOF数据比较完整。
3.可以配置AOF的同步策略，有三种策略可以选择，一种是每次写入一条数据就执行一次同步，一种是每隔一秒执行一次同步，一种是不主动执行同步。
always: 每次写入一条数据，立即将这个数据对应的写日志同步到磁盘中去，性能非常差，吞吐量很低，确保说redis里的数据一条都不丢。
mysql->内存策略，大量磁盘，OPS到多少，1k~2k，QPS每秒钟的请求数量<br>redis->内存，磁盘持久化，OPQ到多少，单机，一般来说，上万QPS没问题
everysec：每秒将os cache中的数据同步到磁盘，这个最常用，生产环境一般都这么配置，性能很高，QPS还是可以上万的
no: 仅仅redis负责将数据写入os cache就撒手不管了，然后后面os自己会不时有自己的策略将数据写入磁盘，不可控了。
模拟实验
1.kill -9 杀掉redis进程，重新启动redis进程，发现数据被恢复回来了，从AOF文件中恢复回来的。在appendonly.aof中，可以看到刚写的日志，他们其实就是先写入os cache的，然后1秒以后才同步到磁盘中，才是安全的，不然光是在os cache中，机器只要重启，就什么也没有了。
2.redis进程启动的时候，直接就会从appendonly.aof中加载所有的日志，把内存中数据恢复回来。
AOF rewrite
redis中数据其实是有限的，很多数据很可能会自动过期，可能会被用户删除，可能会被redis用缓存清除算法清除掉。<br>redis中所有数据会不断淘汰掉旧的，就一部分常用的数据会被自动保留在redis内存中。<br>所以可能很多之前的已经被清理掉的数据，对应的写日志还停留在AOF中，AOF日志文件就一个，会不断的膨胀，到很大很大。<br>所以AOF会自动在后台每隔一定时间做rewrite操作，比如日志里已经存放了针对100w数据的写日志了，redis内存就只剩下10w;基于内存中当前的10万数据构成一套最新的日志到AOF中；覆盖之前的老日志，确保AOF日志文件不会过大，保持和redis内存数据量一致。
在redis中，可以配置rewrite的策略<br>auto-aof-rewrite-percentage 100<br>auto-aof-rewrite-min-size 64mb<br>比如说上一次AOF rewrite操作，是128mb，然后就会接着128mb继续写aof的日志，如果发现增长的比例，超过了之前的100%， 256mb，就可能去触发一次rewrite，但是此时还是要和min-size， 64mb去做比较， 256mb>64mb，才会触发rewrite
工作流程
1.redis fork一个子进程
2.子进程基于当前内存中的数据，构建日志，开始往一个新的临时的AOF文件中写入日志
3.redis主进程，接收到client新的写操作以后，在内存中写入日志，同时新的日志也继续写入旧的AOF文件
4.子进程写完新的日志文件后，redis主进程将内存中的新日志再次追加到新的AOF文件中
5.用新的日志文件替换掉旧的日志文件
RDB VS AOF
区别
1.RDB也可以做冷备，生成多个文件，每个文件都代表了某一个时刻的完整数据快照，AOF也可以做冷备，只有一个文件，但是你可以每隔一段时间，去copy一份这个文件出来
2.RDB每次写，都是直接写redis内存，只是在一定的时候，才会将数据写入磁盘中，AOF每次都是要写文件的，虽然可以快速写入os cache中，但是还是有一定的时间开销，速度比RDB慢一些。
3.AOF存放指令日志，做数据恢复时，其实是要回访和执行所有的指令日志，来恢复出来内存中所有的数据的，RDP就是一份数据文件，恢复的时候，直接加载到内存中即可。
同时工作
1.如果RDB在执行snapshotting操作，那么redis不会执行AOF rewrite，如果redis在执行AOF rewrite,那么就不会执行RDB snapshotting
2.如果RDB在执行snapshotting，此时用户执行BGREWRITEAOF命令，那么等RDB快照生成后，才会执行AOF rewirte
3.同时有RDB snapshot文件和AOF日志文件，那么redis重启的时候，会优先使用AOF进行数据恢复，因为其中的日志会更完整。
