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%的资源

两种备份方式

如何恢复：

将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