前言
快照触发条件
RDB生成快照可自动促发，也可以使用命令手动触发，以下是redis触发执行快照条件，后续会对每个条件详细说明：
- 客户端执行命令save和bgsave会生成快照；
- 根据配置文件save m n规则进行自动快照；
- 主从复制时，从库全量复制同步主库数据，此时主库会执行bgsave命令进行快照；
- 客户端执行数据库清空命令FLUSHALL时候，触发快照；
- 客户端执行shutdown关闭redis时，触发快照；
save命令触发
客户端执行save命令，该命令强制redis执行快照，这时候redis处于阻塞状态，不会响应任何其他客户端发来的请求，直到RDB快照文件执行完毕，所以请慎用。
实践操作：
首先使用info Persistence查看最近一次持久化时间：
此时我们执行save命令，并再次查看最新快照保存时间已经是最新一次时间：
当然你也可以直接查看RDB数据文件目录下的RDB文件最新时间：
bgsave命令触发
bgsave命令可以理解为background save即：“后台保存”。当执行bgsave命令时，redis会fork出一个子进程来执行快照生成操作，需要注意的redis是在fork子进程这个简短的时间redis是阻塞的（此段时间不会响应客户端请求，），当子进程创建完成以后redis响应客户端请求。其实redis自动快照也是使用bgsave来完成的。
为了能清楚了解bgsave工作过程，以下将图文详细描述其工作过程：
对上述过程描述：
- 客户端执行bgsave命令，redis主进程收到指令并判断此时是否在执行bgrewriteaof(AOF文件重新过程，后续会讲解)，如果此时正好在执行则bgsave直接返回，不fork子进程，如果没有执行bgrewriteaof重写AOF文件，则进入下一个阶段；
- 主进程调用fork方法创建子进程，在创建过程中redis主进程阻塞，所以不能响应客户端请求；
- 子进程创建完成以后，bgsave命令返回“Background saving started”，此时标志着redis可以响应客户端请求了；
- 子经常根据主进程的内存副本创建临时快照文件，当快照文件完成以后对原快照文件进行替换；
- 子进程发送信号给redis主进程完成快照操作，主进程更新统计信息（info Persistence可查看）,子进程退出；
实践操作：
执行bgsave
查看日志，能看到6MB文件内存副本写到了磁盘上，同时打印“Background saving terminated with success”代表文件bgsave操作完成。
此时我们查看统计信息最后一次RDB保存时间已经更新：
save m n规则触发
save m n规则说明：在指定的m秒内，redis中有n个键发生改变，则自动触发bgsave。该规则默认也在redis.conf中进行了配置，并且可组合使用，满足其中一个规则，则触发bgsave，在上篇博文也进行了解释，如下：
以save 900 1为例，表明当900秒内至少有一个键发生改变时候，redis触发bgsave操作。
实践操作：
我们改变一个键，满足save 900 1 ：
此时查看redis日志，会发现redis立即响应开始bgsave操作：
FLUSHALL触发
flushall命令用于清空数据库，请慎用，当我们使用了则表明我们需要对数据进行清空，那redis当然需要对快照文件也进行清空，所以会触发bgsave。
实践操作：
日志：
shutdown触发
shutdown命令触发就不用说了,redis在关闭前处于安全角度将所有数据全部保存下来，以便下次启动会恢复。
实践操作：
可以使用客户端连入执行shutdown命令，也可以直接使用脚本关闭redis,这里我使用init脚本（系统centos6.X）。
查看日志：
主从触发
在redis主从复制中，从节点执行全量复制操作，主节点会执行bgsave命令，并将rdb文件发送给从节点，该过程会在复制篇中进行阐述。
故障恢复
上面提及到过，当redis意外崩溃或者关闭再次启动时，此时AOF持久化未开启时(默认未开启)，将使用RDB快照文件恢复数据。
下面我们停用redis服务来模拟故障情况，让再启动redis服务：
观察日志会发现，启动时候load RDB文件。
RDB持久化配置
