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持久化