RDB的问题
1：fork
一个进程时，内存的数据也被复制了，即内存会是原来的两倍
2：每次快照持久化都是将内存数据完整写入到磁盘一次，并不是增量的只同步脏数据。
如果数据量大的话，而且写操作比较多，必然会引起大量的磁盘io操作，可能会严重影响性能。
3：由于快照方式是在一定间隔时间做一次的，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改。
触发快照的情况
1：根据配置规则进行自动快照
2：用户执行save或bgsave命令
3：执行flushall命令
4：执行复制replication时
save命令执行
Save命令时，Redis会阻塞所有客户端的请求，然后同步进行快照操作。
bgsave命令
执行bgsave命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间。
flushall命令
这个命令会导致redis清除内存中的所有数据，如果定义了自动快照的条件，那么无论是否满足条件，都会进行一次快照操作；如果没有定义自动快照的条件，那么就不执 行快照
AOF的问题
默认的AOF持久化策略是每秒钟fsync一次，fsync是指把缓存中的写指令记录到磁盘中，
在这种情况下，redis扔可以保持很高的性能
当然由于OS会在内核中缓存write做的修改，所以可能不是立即写到磁盘上。
这样aof方式的持久化也还是有可能会丢失部分修改。不过可以通过配置文件告诉redis，想要通过fsync函数强制os写入磁盘的时机
AOF方式在同等数据规模的情况下，AOF文件要比RDB文件的体积大，因此AOF方式的恢复速度也要慢于RDB方式
AOF日志恢复
如果在追加日志时，恰好遇到磁盘空间满或断电等情况，导致日志写入不完整，也没有关系，
redis提供了redis-check-aof工具，可以用来进行日志修复，基本步骤如下：
1、备份被写坏的AOF文件
2、运行redis-check-aof -fix进行修复
3、用diff -u来看下两个文件的差异，确认问题点
4、重启redis，加载修复后的AOF文件
AOF重写
AOF采用文件追加方式，这样会导致AOF文件越来越大，为此，redis提供了AOF文件重写（rewrite）机制，即当AOF文件的大小超过所
设定的阈（yu）值时，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。可以使用命令bgrewriteaof.