在之前的博文中已经详细的介绍了redis4.0基础部分，并且在memcache和redis对比中提及redis提供可靠的数据持久化方案，而memcache没有数据持久化方案，本篇博文将详细介绍redis4.0所提供的持久化方案：RDB持久化和AOF持久化以及redis4.0新特性混合持久化。这里将从原理到配置以及相关实践进行说明，希望能对你有所帮助。
一、RDB持久化 简介RDB持久化方式是通过快照(snapshotting)完成的，当符合一定条件时，redis会自动将内存中所有数据以二进制方式生成一份副本并存储在硬盘上。当redis重启时，并且AOF持久化未开启时，redis会读取RDB持久化生成的二进制文件(默认名称dump.rdb，可通过设置dbfilename修改)进行数据恢复，对于持久化信息可以用过命令“info Persistence”查看。
快照文件位置RDB快照文件存储文件位置由dir配置参数指明，文件名由dbfilename指定，如下：
快照触发条件
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保存时间已经更新：