在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。
1、备份是如何执行的
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
2、Fork
-
Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。
-
在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”。
-
一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。
3、RDB持久化流程
4、优势
1、适合大规模的数据恢复
2、对数据完整性和一致性要求不高更适合使用
3、节省磁盘空间
4、恢复速度快
5、劣势
1、子进程进行持久化的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
2、虽然Redis在子进程进行持久化时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
3、在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。
AOF以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
1、AOF持久化流程
（1）客户端的请求写命令会被append追加到AOF缓冲区内
（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中
（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量
（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的
2、AOF和RDB同时开启，redis听谁的？
AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）
3、AOF启动/修复/恢复
AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。
1）正常恢复
-
修改默认的appendonly no，改为yes
-
将有数据的aof文件复制一份保存到对应目录(查看目录：config get dir)
-
恢复：重启redis然后重新加载
2）异常恢复
-
修改默认的appendonly no，改为yes
-
如遇到AOF文件损坏，通过/usr/local/bin/redis-check-aof--fix appendonly.aof进行恢复
-
备份被写坏的AOF文件
-
恢复：重启redis，然后重新加载
4、AOF同步频率设置
1）appendfsync always
始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好
2）appendfsync everysec
每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
3）appendfsync no
redis不主动进行同步，把同步时机交给操作系统。
5、Rewrite压缩
1）是什么？
AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof
2）重写原理，如何实现重写
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，redis4.0版本后的重写，是指上就是把rdb 的快照，以二级制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。
3）no-appendfsync-on-rewrite
如果 no-appendfsync-on-rewrite=yes ,不写入aof文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）
如果 no-appendfsync-on-rewrite=no, 还是会把数据往磁盘里刷，但是遇到重写操作，可能会发生阻塞。（数据安全，但是性能降低）
4）触发机制，何时重写
Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发
重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。
-
auto-aof-rewrite-percentage：设置重写的基准值，文件达到100%时开始重写（文件是原来重写后文件的2倍时触发）
-
auto-aof-rewrite-min-size：设置重写的基准值，最小文件64MB。达到这个值开始重写。
例如：文件达到70MB开始重写，降到50MB，下次什么时候开始重写？100MB
系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为base_size,如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。
5）重写流程
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重写。
6、优势
1、备份机制更稳健，丢失数据概率更低。
2、可读的日志文本，通过操作AOF稳健，可以处理误操作。
7、劣势
1、比起RDB占用更多的磁盘空间。
2、恢复备份速度要慢。
3、每次读写都同步的话，有一定的性能压力。
4、存在个别Bug，造成恢复不能。
Redis 持久化方案的建议
1、如果Redis只是用来做缓存服务器，比如数据库查询数据后缓存，那可以不用考虑持久化，因为缓存服务失效还能再从数据库获取恢复。
2、如果你要想提供很高的数据保障性，那么建议你同时使用两种持久化方式。
3、如果你可以接受灾难带来的几分钟的数据丢失，那么可以仅使用RDB。
4、通常的设计思路是利用主从复制机制来弥补持久化时性能上的影响。即Master上RDB、AOF都不做，保证Master的读写性能，而Slave上则同时开启RDB和AOF（或4.0以上版本的混合持久化方式）来进行持久化，保证数据的安全性。
