redis可以通过创建快照来获得某个时间点上的内存内容的数据副本，有了副本之后，就可以将副本发送到其他redis服务器上从而创建相同数据的从服务器，同时快照留在原地以便重启redis的时候实现数据恢复。

     save 60 1000  快照生成策略  如果服务器距离上一次成功生成快照已经超过六十秒，并且期间执行了至少1000次写操作。

     stop-writes-on-bgsave-error yes 创建快照文件失败后是否继续执行写命令

     rdbcompression yes   是否对快照文件进行压缩

     dbfilename dump.rdb  快照文件名称

     dir /opt/redis-2.8.13/dmp/  持久化文件保存的路径

     1，向redis发送bgsave命令，redis会调用fork来创建一个子进程，子进程负责创建快照，父进程继续处理命令请求。

     2，向redis发送save命令，父进程停止响应其他命令，开始进行快照创建，save命令通常不用，一般在没有足够内存执行bgsave的时候或者让客户端等待也没关系的时候使用。

     3，根据用户设置的save 策略配置信息，进行执行。如果配置多个，只要满足一个就执行。

     4，redis接收到shutdown或者标准term命令的时候，会触发save命令，创建快照。

     5，当从服务器链接到主服务器并且发送sync命令来同步数据的时候，并且这个时候主服务器没有在执行bgsave或者不是刚刚执行完bgsave的话，就创建个快照，以供复制使用。

     当内存数据量不那么大的时候，使用快照持久化比较不错。但是如果数据量达到了十几个G以上的那种，执行一个bgsave会特别慢，save的话会快点，但是也会耗费比较多时间，并且快照文件也比较大。这个时候就需要使用AOF持久化了。

     简单来说，AOF持久化会将执行的写命令写到AOF文件末尾来记录所有的变化。redis只要从头到尾执行一次AOF文件的命令，就可以进行数据恢复了。

     appendonly yes  是否打开AOF持久化

     appendfilename "appendonly.aof"  持久化文件名称

     # appendfsync always  每次redis写命令都进行持久化，这样会严重降低redis速度，但是数据基本不丢失

     appendfsync everysec     每秒进行一次，丢失数据也是一秒内的

     # appendfsync no     让操作系统自己决定什么时候执行

     no-appendfsync-on-rewrite no

     auto-aof-rewrite-percentage 100  当aof文件比上次重写之后体积大了至少100%，进行重写

     auto-aof-rewrite-min-size 64mb     当体积岛屿64M的时候重写

     上面这两个条件同时符合的时候才重写。

     dir /opt/redis-2.8.13/dmp/  持久化文件保存的路径

     AOF文件由于会不断的追加写入命令，因此体积会越来越大，这时向redis发送bgrewriteaof命令，可以重写aof，将其中的冗余命令删除掉，减小体积，也是主进程fork出一个子进程来处理。针对这个命令也可以配置一下让redis自己维护执行。

     当redis服务器挂掉时，重启时将按照以下优先级恢复数据到内存：

     如果只配置AOF,重启时加载AOF文件恢复数据；（将rdb的配置信息都注释掉就关闭了rdb，只要不主动发送bgsave命令就不持久化了）

     如果同时 配置了RBD和AOF,启动是只加载AOF文件恢复数据;

     如果只配置RBD,启动是讲加载dump文件恢复数据。