一、RDB（Redis DataBase）

1、RDB是什么

在指定的时间间隔内将内存中的数据集快照写入磁盘， 也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。

2、RDB如何执行

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。

（1）Fork

 Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程；

在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”；

一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

（2）RDB执行流程图

 3、RDB的特点 

在备份的整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

RDB的缺点是最后一次持久化后的数据可能丢失。因为假设配置RDB在20秒内，当数据出现三次变化后，开始快照。那么在最后一个20秒内服务器挂掉，在这个时间段内更新的数据都无法保存。

4、RDB的优缺点 

（1）优点

1、适合大规模的数据恢复

2、对数据完整性和一致性要求不高更适合使用

3、节省磁盘空间

4、恢复速度快

（2）缺点    

1、Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑；

2、虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能；

3、在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

 5、RDB小总结 

二、AOF（Append Only File）

1、AOF是什么 

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

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

 2、AOF持久化流程 

（1）客户端的请求写命令会被append追加到AOF缓冲区内；

（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；

（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件进行rewrite重写，压缩AOF文件容量；

（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

  3、开启AOF的方法 

AOF默认不开启。

在配置文件中修改默认的appendonly no，改为yes，即可开启AOF持久化。

4、同时开启AOF和RDB，Redis听谁的？ 

当AOF和RDB同时开启时，系统默认取AOF的数据（数据不会丢失）。

5、AOF的启动、恢复和修复

（1）启动 

AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。 

（2）正常恢复 

 Redis重启后，会重新读取appendonly.aof中的数据。

（3）异常恢复（修复）

如果遇到aof文件损坏，可以通过命令进行修复

redis-check-aof--fix appendonly.aof

6、rewrite压缩

（1）rewrite简述，重写是什么？

 AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof。

（2）rewrite原理，如何重写？

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，redis4.0版本后的重写，是指上就是把rdb 的快照，以二级制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。

具体流程：

       1、bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。

       2、主进程fork出子进程执行重写操作，保证主进程不会阻塞。

       3、子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。

       4、①子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。

             ②主进程把aof_rewrite_buf中的数据写入到新的AOF文件。

       5、使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。

（3）rewrite的触发机制，何时重写？

重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。  

Redis会记录上次重写时的AOF大小，当AOF文件大小是上次rewrite后大小的两倍且文件大于auto-aof-rewrite-min-size（默认为64M）时触发。

系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为base_size,如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。

 例如：文件达到70M时开始重写，重写后降为50M，那么下次达到100M时开始重写。

8、AOF的优缺点

（1）优点

1、备份机制更稳健，丢失数据概率更低；

2、可读的日志文本，通过操作AOF稳健，可以处理误操作。

（2）缺点

 1、比起RDB占用更多的磁盘空间；

 2、恢复备份速度要慢；

 3、每次读写都同步的话，有一定的性能压力；

 4、存在个别Bug，造成恢复不能。

   9、AOF小总结 

三、总结，用哪个好

都使用？                官方推荐！

单独用RDB？        数据不敏感的情况下可以

单独用AOF？        不推荐，可能会出现bug

都不用？                做纯内存缓存的情况下可以