11.redis持久化

RDB操作

在指定的时间间隔内将内存中的数据集快照写入磁盘 它恢复时是将快照文件直接读到内存中

单独创建一个子进程进行持久化，先将数据写到一个临时的文件中，持久化结束之后 用临时我呢见替换上次持久化好的文件。整个过程中国 主进程是不进行任何I/O擦操作的 确保了性能

RDB的缺点是最后一次持久化的数据可能丢失 默认就是RDB 一般情况西不需要修改配置

RDB保存的文件时=是dump.rdb

触发机制：

1.save的规则满足的情况下，会自动触发rdp规则

2.执行flushall命令，也会触发rdb规则

3.退出redis,也会产生rdb

备份完之后就会自动生成一个rdb文件

如何恢复rdb文件：

1.只需要将rdb文件放到redis的启动目录下就可以 redis 启动的时候会自动检查dump.rdb 恢复其中的数据

2.查看需要存放的位置"/usr/local/bin"

127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin"  #如果在这个目录下存在dump.rdb 文件 启动会自动恢复其中的数据
优点：

1.适合大规模的数据恢复

2.如果对数据完整性要求不高

缺点：

1.需要一定的时间间隔进行操作 如果redis意外宕机 最后一次修改的数据就没有了

2.fork进程的时候 会占用一定的内存空间

 

AOF操作（Append only file）

将所有命令都记录下来，恢复的时候把这个文件全部再执行一遍

以日志的形式记录每一个写的操作，将redis执行过程中的所有命令记录下来，只允许追加文件但不可以改文件，redis启动之初回读取该文件重新构建数据，换言之，redis重启的话就根据日志的内容将写指令从前到后执行一次完成数据的恢复

 

默认是不开启的 需要手动配置 将appendonly 由no改成yes  重启redis之后即可生效

如果这个aof文件由错误，这时候redis是不能正常启动的，我们需要修复这个aof文件  redis提供了一个工具 redis-check-aof --fix appendonly.aof

如果文件正常 重启就可以修复

重写规则说明：如果aof文件大于64MB 就会fork一个新的进程来将文件进行重写，超过这个大小 会触发一个重写的机制

aof默认就是文件的无限增加

rewrite

优点：

1.每一次修改都同步，文件的完整性就更加好

2.默认是每秒同步一次，可能会丢失一秒的数据

3.从不同步，效率最高

缺点：

1.相对于数据文件来说，aof远远大于rdb,修复的速度也比rdb慢

2.运行效率也比rdb慢，redis默认开启的是rdb文件