Redis的持久化
Redis的持久化一共有两种：
rdb持久化
aof持久化（推荐使用）
RDB（Redis Database）
什么是rdb持久化
在指定的时间间隔内将内存中的数据集快照写入磁盘，
也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。
Redis官方解释：
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到
一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能
如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方
式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
（因为可能出现redis宕机的情况）
Fork的解释
fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
Rdb持久化详解
rdb 持久化内容保存在一个文件中默认是dump.rdb文件。可以在redis.conf配置文件中设置。
Redis是如何触发如何触发RDB快照的？
解析redis.conf配置文件我们可以发现rdb快照的策略：
在900秒（15分钟）内有1个key值修改 或
在 300秒（5分钟）内有10个key值修改 或
在 60秒（1分钟）内有10000个key值修改 那么就会触发快照，重新写dump.rdb文件。
这里我们可以测试一下，先将redis服务关闭，再将dump.rdb文件删除。
需要注意的是：redis关闭时和flushAll时都会自动的去更新dump.rdb文件的。
将redis快照策略改动下，改成2分钟修改10次后便去更新dump.rdb文件。
然后我们在两分钟内对10个key进行操作后，两分钟后就会生成一个dump.rdb文件了。
我这里测试是没有问题的。。。
手动触发快照
save和bgsave
save:普通的触发快照
bgsave：
redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。
可以通过lastsave命令获取最后一次成功执行快照的时间。
如何禁用快照？
如果想禁用RDB持久化的策略，只要不设置任何save指令，或者给save传入一个空字符串参数也可以。
redis初始化配置文件已经有了示范了。
如何恢复快照？
我们可以写一个脚本，脚本内容是定时的去copy 当前redis生成dump.rdb文件，备份到其它台机器上。
恢复快照：
将copy的文件放到redis/bin下并启动redis就ok了。
因为redis启动时会去找快照文件并将其内容读到内存中。
在redis.conf 与 Rdb相关的一些配置
dbfilename：
配置rdb快照文件
stop-writes-on-bgsave-error：
如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制
rdbcompression：对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能。
一般都不会去改变的。
rdbchecksum：在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。
一般都不会去改变的。
RDB总结
优势：
（1）适合大规模的数据恢复
（2）对数据完整性和一致性要求不高
劣势：
（1）在一定间隔时间做一次备份，所以如果redis意外down掉的话，就
会丢失最后一次快照后的所有修改
（2）fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
AOF（Append Only File）常用
什么是aof持久化？
Aof持久化：
以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，
只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis
重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
AOF持久化启动/修复/恢复
启动aof持久化：
修改内容：
appendonly no修改成appendonly yes开启aof持久化，redis默认是关闭aof持久化的
修改完成后重新下redis，就可以发现aof文件出来的。
注意：两个持久化同时存在，redis优先选择aof持久化。
恢复数据：
两种情况：redis正常关闭，redis异常关闭
Redis正常关闭：
正常重新启动redis就可以恢复数据了。因为redis会将记录下来的aof文件执行一遍，这样恢复到了原来的数据了。（aof会记录下所有的写操作）
Redis异常关闭：
先修复aof文件：redis-check-aof --fix appendonly.aof，这里会将错误的数据修改。
重启redis然后重新加载，原理和正常关闭的一致。
Rewrite
rewrite：
AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,
当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，
只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof
重写原理：
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。
rewrite触发机制：
Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发
no-appendfsync-on-rewrite：
重写时是否可以运用Appendfsync，用默认no即可，保证数据安全性。
auto-aof-rewrite-min-size：
设置重写的最小触发值，默认是64mb
auto-aof-rewrite-percentage：
设置重写的基准值，默认是100，意思是100%
Aof相关配置详解
appendonly：
设置是否开启aof持久化，默认是no，如果需要开启改成yes
appendfilename：
指定aof持久化保存文件的名字
appendfsync：
redis写操作的追加策略，有三种
always：同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好
everysec：出厂默认推荐，异步操作，每秒记录，如果一秒内宕机，有数据丢失，这是常用。
no：从不同步。
AOF总结
优势：
每修改同步：
appendfsync always同步持久化，每次发生数据变更会被立即记录到磁盘 ，性能较差但数据完整性比较好
每秒同步：
appendfsync everysec 异步操作，每秒记录，如果一秒内宕机，有数据丢失
不同步：
appendfsync no从不同步
劣势：
相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb。
aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同