向主进程发送信号，通知保存已完成。因为rdbSave 在子进程被调用，所以 Redis 服务器在BGSAVE 执行期间仍然可以继续处理客户端的请求。
1.2、运行例子
a、启动redis
b、物理磁盘
c、内置客户端操作
d、终止客户端
e、重启redis
?
?
2、AOF
快照功能并不是非常耐久（durable）： 如果 Redis 因为某些原因而造成故障停机， 那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。
1.1、运作方式
?
Redis 执行 fork() ，现在同时拥有父进程和子进程。子进程开始将新 AOF 文件的内容写入到临时文件。对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾： 这样即使在重写的中途发生停机，现有的 AOF 文件也还是安全的。当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新 AOF 文件的末尾。
?
搞定！现在 Redis 原子地用新文件替换旧文件，之后所有命令都会直接追加到新 AOF 文件的末尾。
1.2、保存模式
?
每次有新命令追加到 AOF 文件时就执行一次 fsync ：非常慢，也非常安全。每秒 fsync 一次：足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据。从不 fsync ：将数据交给操作
系统来处理。更快，也更不安全的选择。
?
推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。
1.3、读取和还原数据
?
Redis 读取 AOF 文件并还原数据库的详细步骤如下：
?
? 创建一个不带网络连接的伪客户端（fakeclient）。
? 读取 AOF 所保存的文本，并根据内容还原出命令、命令的参数以及命令的个数。
? 根据命令、命令的参数和命令的个数，使用伪客户端执行该命令。
? 执行 2 和 3 ，直到 AOF 文件中的所有命令执行完毕。
完成第 4 步之后， AOF 文件所保存的数据库就会被完整地还原出来。
1.4、例子
a、修改redis配置文件(这里是关闭rdb，而且运行模式为每次更新一次aof文件)
b、重启redis
c、客户端进行连接并操作
d、终止redis并重启
?
?
?
3、RDB+AOF
Redis同时运行着rdb和aof两种模式
那么当 Redis 启动时，程序会优先使用 AOF 文件来恢复数据集， 因为 AOF 文件所保存的数据通常是最完整的
1、运行例子
a、修改redis配置文件，设置同时启动rdb和aof
b、启动redis
c、客户端操作数据
d、终止redis
?
?
五、总结
1、redis 支持rdb和aof等两种持久方式，如果都关闭rdb和aof等方式。则可以把redis看成是内存缓存
2、如果rdb和aof都开启，则优先考虑aof
3、rdb可以看成是保存数据结果，而aof则是记录修改/写入等操作
4、根据rdb和aof的作用，可以用rdb作为完全备份，而把aof作为增量备份