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一个线程进行备份的时候可能会出现性能的下降