一、RDB持久化
1、有两个Redis命令可以用于生成RDB文件，一个是SAVE，另一个是BGSAVE
(1) SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止。在服务器进程阻塞期间，服务器不能处理任何命令请求。
(2) BGSAVE命令会派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程(父进程)不受影响。
2、在Redis数据进行恢复的时候，由于AOF文件的更新频率通常比RDB文件的更新频率高，所以遵循以下规律：
(1) 如果服务器开启了AOF持久化功能，那么服务器会优先使用AOF文件来还原数据库状态
(2) 只有在AOF持久化功能处于关闭状态时，服务器才会使用RDB文件来还原数据库状态
3、BGSAVE 的自动间隔性保存功能
如果在Redis提供了以下配置：
save 900 1
save 300 10
save 60 10000
那么只要满足以下三个条件中的一个，BGSAVE 命令就会被执行：
服务器在900秒之内，对数据库进行了至少1次修改
服务器在300秒之内，对数据库进行了至少10次修改
服务器在60秒之内，对数据库进行了至少10000次修改
二、AOF持久化
1、AOF持久化是通过保存用户执行的每个命令来实现的，其写入和同步的方式由 appendfsync 参数控制，有以下三个选项：
(1) always：服务器在每个事件循环都需要将aof_buf 缓冲区中的所有内容写入到AOF文件，并且同步AOF文件。效率最低，安全最高。
(2) everysec：服务器在每个事件循环都需要将aof_buf 缓冲区中的所有内容写入到AOF文件，并且每隔一秒就要在子线程中对AOF文件进行一次同步。所以就算Redis实例出现故障停机，也只丢失一秒钟的数据。
(3) no：服务器在每个事件循环都需要将aof_buf 缓冲区中的所有内容写入到AOF文件，至于何时对AOF文件进行同步，则有操作系统控制，Redis实例无须执行同步操作。效率最高，安全最低。
2、随着Redis服务的运行，AOF会记录越来越多的命令，AOF文件体积就会越来越大。Redis提供了AOF文件重写功能来解决该问题。
通过使用 BGREWEITEAOF 命令，Redis将生成新的AOF文件替换旧的AOF文件。但是其过程并不是在老的AOF文件基础上进行的，而是 通过读取服务器当前的数据库状态 来实现的。
AOF重写采用的是子进程的方式在后台运行，但是会出现这样一种情况：子进程在重写期间，新的命令对现有数据库进行了修改，这样导致了重写后的AOF文件与当前数据库状态不一致。解决该问题的方式是 在AOF重写期间，新的命令写入AOF缓存区的同时，也发送到AOF重写缓存区。
