备份原理

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效

优点

紧凑压缩的二进制文件 节省空间
fork子进程性能最大化
启动效率高 恢复速度快

缺点

一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据
虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能
fork过程非常耗时，会造成毫秒级不能响应客户端请求

AOF

写一条，保存一条，历史的状态

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，Redis启动之初会读取该文件重新构建数据，换言之，Redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

不能保证绝对不丢失数据

执行系统调用write函数，将一些内容写入到某个文件里面时，为了提高效率，系统通常不会直接将内容写入硬盘里面，而是先将内容放入一个内存缓冲区(buffer)里面，等到缓冲区被填满，或者用户执行fsync调用和fdatasync调用时才将储存在缓冲区里的内容真正的写入到硬盘里，未写入磁盘之前，数据可能会丢失

重写

原因

比如我有业务很简单，就来回delete set同一个key。就这个业务运行了10年，那么aof文件将记录无数个delete k上，set k1x。其实都是重复的，但是我aof每次都追加，文件变成了1T大小。这时候Redis宕机了，要恢复，你想想1TB大小的aof文去恢复，累死了。最主要的是1TB大小只记录了两个命令，所以压缩其实就是来处理这件事的

流程

Redis可以在AOF文件体积变得过大时，自动地在后台对AOF进行rewrite。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行
因为Redis在创建新AOF文件的过程中，会继续将命令追加到现有的AOF文件里面，即使重写过程中发生停机，现有的AOF文件也不会丢失。
而一旦新AOF文件创建完毕，Redis就会从旧AQF文件切换到新AOF文件，并开始对新AOF文件进行追加操作

结论

合并重复的操作，AOF会使用尽可能少的命令来记录

优点

备份机制更稳健，丢失数据概率更低。
可读的日志文本，通过操作AOF稳健，可以处理误操作

缺点

比起RDB占用更多的空间
恢复备份速度慢
每次读写都同步的话,有一定的性能压力
存在一个别的Bug,造成恢复不能

如何选择RDB和AOF

同时开启

Redis先加载AOF文件来恢复原始数据，因为AOF数据比RDB地更完整，但是aof存在潜在的bug,如把错误的操作记录写入了aof,会导出数据恢复失败，所以可以把RDB作为后备数据。
为了考虑性能，可以只在Slave上开启RDB,并且15min备份一次，如果为了避免AOF rewite的Io以及阻塞，可以在Redis集群中不开启AOF,靠集群的备份机制来保证可用性，在启动时选取较新的RDB文件，如果集群全部崩溃，会丢失15mi前的数据。