Redis：持久化（RDB，AOF）

RDB和AOF是redis持久化的基本！

一，RDB（Redis DataBase）

在指定的时间间隔内将内存中的数据集快照写入磁盘，实现持久化，也就是Snapshot快照，它恢复时是将快照文件直接读到内存里

RDB工作过程：

　　Redis会单独创建一个（fork）子进程来进行持久化，他的数据来源于（OS写的复制机制）父进程与它的共享内存中，fork会将数据写入到一个临时文件中，等到持久化都结束了，再用这个临时文件替换上次持久化好的文件，整个过程中，主进程时不进行任何IO操作的，因此确保了主进程极高的性能；

使用场景：

　　如果需要进行大规模数据的恢复，且对于数据的完整性要求不是那么高的话，RDB一定会比AOF要更加高效

RDB缺点：

　　1.由于RDB的工作特点，在上一次持久化数据没结束，但父进程却意外关闭，就会最后一次快照没有持久化到正式EDB文件中，导致数据不完整

　　2.fork子进程需要一定的内存空间

RDB文件保存的位置： dump.rdb

save触发机制：

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

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

3，推出redis，也会产生reb文件

备份就自动生成了dump.rdb

 恢复rdb文件

1.将rdb文件放到redis的启动目录下就可以了，redis启动会自动检查dump.rdb回复其中数据

2.查看rdb应该存放的位置

二，AOF（Append Only File）

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

 

说明：

以日志的形式记录每个写操作，将Redis执行过的所有指令记录下来（读操作不记录），只需追加文件但不可以改写文件，redis启动时会读取该文件重新构建数据，

通俗的说，重启Redis时会根据aof文件里的写指令，从头到尾重新构建一遍

Aof保存的是appendonly.aof文件

AOf在Redis配置文件中的位置（appendonly）

 默认不开启的，需要手动进行! 仅需将appendonly改为yes就开启了aof

重启redis就可以生效

如果aof文件有错，redis是启动不起来的，因此需要修复这个aof文件

解决方法：redis提供了一个工具，在redis启动目录下运行redis-check-aof  --fix

优点和缺点

优点：

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

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

3，从不同步，效率最高

缺点：

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

2， Aof运行效率要比rdb慢，所以我们redis默认的配置就是rdb持久化