1，快照持久化
1简介
redis可以通过创建快照来获得某个时间点上的内存内容的数据副本，有了副本之后，就可以将副本发送到其他redis服务器上从而创建相同数据的从服务器，同时快照留在原地以便重启redis的时候实现数据恢复。
2配置
save 60 1000 快照生成策略 如果服务器距离上一次成功生成快照已经超过六十秒，并且期间执行了至少1000次写操作。
stop-writes-on-bgsave-error yes 创建快照文件失败后是否继续执行写命令
rdbcompression yes 是否对快照文件进行压缩
dbfilename dump.rdb 快照文件名称
dir /opt/redis-2.8.13/dmp/ 持久化文件保存的路径
3快照文件生成的时机
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持久化了。
2，AOF持久化
1简介
简单来说，AOF持久化会将执行的写命令写到AOF文件末尾来记录所有的变化。redis只要从头到尾执行一次AOF文件的命令，就可以进行数据恢复了。
2，配置
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/ 持久化文件保存的路径
3，AOF文件重写
AOF文件由于会不断的追加写入命令，因此体积会越来越大，这时向redis发送bgrewriteaof命令，可以重写aof，将其中的冗余命令删除掉，减小体积，也是主进程fork出一个子进程来处理。针对这个命令也可以配置一下让redis自己维护执行。
3，数据恢复
当redis服务器挂掉时，重启时将按照以下优先级恢复数据到内存：
如果只配置AOF,重启时加载AOF文件恢复数据；（将rdb的配置信息都注释掉就关闭了rdb，只要不主动发送bgsave命令就不持久化了）
如果同时 配置了RBD和AOF,启动是只加载AOF文件恢复数据;
如果只配置RBD,启动是讲加载dump文件恢复数据。