redis持久化的两种策略
RDB（redis database）：在指定时间将内存中的快照（snapshot）写入到磁盘中进行持久化，恢复的时候直接将其读入到内存中。
怎么实现的：
redis单独fork一个线程出来，进行持久化，不会打扰主线程的高速运行，如果进行大规模的数据的恢复，同时对数据的丢失的敏感性不高的话，可以是使用该方法，不过只能恢复最新的备份的数据，会把最新备份之后的数据全部丢失
fork：复制一个完全一摸一样的线程，什么内存空间啥的都一样的线程，可能拖慢主线程的运行
dump.rdb:
什么时候触发保存：
1、900s内出现1次key的改动
2、300s内出现10次key的改动
3、60s内出现10000次key的改动
什么时候会触发dump
shatdown redis的时候，默认会去dump当前redis中的keys
禁用备份
在conf中写一个
save ""
如果要即时生效配置
set key value
save命令，即时生成dump.rdb
一些配置
stop-writes-on-bgsave-error：如果设置为yes，那么如果备份错误的时候，会拒绝写入的，如果设置为no，那么不会拒绝这些东西
rdbacompression：yes（设置为yes，redis会压缩整个dump文件，会耗cpu的资源）
rdbcchecknum：验证这个数据的准确性，会耗费cpu的10%的资源
两种备份方式
- save：啥都不管直接备份，系统不能响应set等命令了
- bgsave：redis新开一个线程在后台备份，不影响客户端的使用，lastsave获取上次备份时间
如何恢复：
将dump.rdb备份到相应的位置，重启redis服务即可
优势
1、大规模恢复
2、对数据的一致性完整性要求不高
劣势
1、备份的最后一次到redis down机的中间的数据就没有了，丢失了
2、fork一个线程进行备份的时候可能会出现性能的下降
aop：append only file
是什么：
redis以日志的方式将所有的写操作记录下来，只需追加文件，不允许改写文件，redis启动之初就会根据这个文件重新构建一遍数据，redis会从头到尾执行一遍整个写操作
如果aof文件和dump文件共存的时候，首先加载aof文件
使用redis-check-aop可以fixaof文件的错误
三种同步策略：
1、always：每次数据改动都要同步到aof文件中，性能较差，数据完成性比较好
2、everysecs：每秒同步一次，如果出现问题，可能会丢失1s内的数据
3、no
rewrite（重写）：aof文件随着文件越来越大，redis会启动文件的压缩，将一些命令合并起来，只保留恢复数据的最小的数据集，可以使用bgrewriteaof命令
重写机制：记录上一次aof文件的大小，这一次的大小是上次的两倍，同时大于64M