RDB :
分为SAVE和BGSAVE，BGSAVE是fork子进程，而SAVE会直接阻塞，这边默认用BGSAVE。
RDB即内存快照，是对 Redis 中的数据执行周期性的持久化。
优点: RDB对Redis的性能影响非常小，是因为在同步数据的时候他只是fork了一个子进程去做持久化的，而且他在数据恢复的时候速度比AOF来的快。
fork函数的cow实现 ，cow指的是copy on write（写时复制）
子进程拥有父进程虚拟地址空间的副本，并且暂时共享父进程的物理内存，对此内存只拥有只读权限缺点：
1.RDB都是快照文件，都是默认五分钟甚至更久的时间才会生成一次，如果宕机会丢失更多的数据
2.还有就是RDB在生成数据快照的时候，如果文件很大，客户端可能会暂停几毫秒甚至几秒，
AOF：
优点：但是AOF一般一秒一次去通过一个后台的线程fsync操作，那最多丢这一秒的数据。
以 append-only 的模式写入一个日志文件中，因为这个模式是只追加的方式，所以没有任何磁盘寻址的开销，所以很快，有点像Mysql中的binlog。
缺点：
1.一样的数据，AOF文件比RDB还要大。
2.AOF开启后，Redis支持写的QPS会比RDB支持写的要低，线程fsync需要每秒都要去异步刷新一次日志嘛
补充：AOF可以用BGREWRITEAOF重写来缩小大小（原理是 原来记录每条更新的命令 变为 记录每个key-value ，这样就不会有命令冗余了），进行这命令操作的时候会有AOF缓冲区和AOF重写缓冲区来保证数据的一致性。
两种策略怎么选择？
两种方式都可以把Redis内存中的数据持久化到磁盘上，然后再将这些数据备份到别的地方去，RDB更适合做冷备，AOF更适合做热备
两种机制全部开启的时候，Redis在重启的时候会默认使用AOF去重新构建数据，因为AOF的数据是比RDB更完整的。
一般是全部开启，先用RDB还原大部分数据，速度比AOF快，然后用AOF补全。
