redis持久化策略

RDB

在指定时间间隔内将内存中的数据快照写进磁盘，也就是Snapshot(快照)，它恢复时是直接将快照文件读进内存

Redis会创建(fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程结束，再用这个临时文件覆盖原先的持久化文件。

整个过程，主线程是不进行任何IO操作，确保了极高的性能，如果需要进行大规模的数据的恢复，且对于数据恢复的完整性不是非常敏感，RDB比AOF高效，因为，RDB只需要读取一次持久化文件（dump.rdb）。

!!RDB缺点是最后一次持久化的数据可能丢失

RDB持久化策略

save 900 1  #在900s内改变一次key,则进行持久化，生产dump.rdb文件
save 300 10 #在300s内改变10次key
save 60 10000 #在60s内改变10000次ky

改变的key越多，持久化间隔越短
下次启动redis，会字段将dump读进内存，恢复数据
1.应该将dump.rdb备份到其它机器上，以免当前机器损坏
2.如果使用 FLUSHALL 清空数据库时，会立刻生产dump.rdb文件，文件为空，也就说下次恢复时，数据也是空。需要注意。。

禁用缓存策略

1.在配置文件中使用 save ""
2.在命令行存储数据后，立刻使用 save 命令

意思就是，立刻对数据进行持久化，而不是等缓存策略生效

AOF(append on file)

以日志的形式来记录每个写操作，将redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动时会读取该文件重新构建数据，根据日志文件从头到尾执行一次所有指令。

！！AOF会把所有操作指令记录下拉，包括FLUSHALL,如果你的操作最后一步是FLUSHALL，需要代开aof文件手动把该命令去掉，不然数据恢复后还是会被清掉

appendonly.aof和dump.rdb 可以共存，但是启动时用的时aof文件。

开启AOF

appendonly no

AOF异常恢复

如果aof文件发生错误，则redis启动失败，有两种解决方法
1.手动修改aof文件，把错误操作指令去除或修复
2.使用redis-check-aof进行修复 redis-check-aof --fix appendonly.aof

AOF策略

no：
always:同步初始化，每次发生数据变更立刻记录到磁盘，性能差但是不会丢失数据
everysec:默认，异步操作，每秒记录，如果一秒内宕机，丢失1s数据

AOF rewrite

AOF文件采用文件追加的方式，文件会越来越大，为了避免这种情况，新增了重写机制，当aof文件大小超过设定的阈值，redis就会启动aof压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof

auto-aof-rewrite-percentage 100 #文件为上次重写文件两倍时进行重写
auto-aof-rewrite-min-size 64mb  #阈值尾64Mb,超过则进行重写

缺点

相同数据值aof文件比rdb文件大，恢复慢。