redis是内存数据库,如果不将内存中的数据库状态保存到磁盘,那么服务器进程一旦退出,服务器中的数据库状态也会消息,所以redis提供了持久化功能。
在主从复制中,rdb就是备用的。

在指定的时间间隔内将内存的数据集快照写入磁盘,也就是行话讲的snapshot快照,它恢复时是将快照文件直接读到内存中。
有时候在生产环境中,我们会将这个文件进行备份。
Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入一个临时文件中 ,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化过程后的数据可能丢失。
我们默认的就是RDB,一般情况下不需要修改。
rdb保存的文件是 dump.rdb,可以在配置文件中快照配置的!
dbfilename dump.rdb
1.save的规则满足的情况下,会自动触发rdb规则
2.执行flushall命令,也会触发我们的rdb规则
3.退出redis,也会产生rdb文件
备份后也会生成dump.rdb文件
1.只需要将rdb文件放在我们的redis启动目录就可以,redis启动的时候就会自动检查dump.rdb恢复其中的数据
2.查看需要存放的位置
127.0.01:6379> config get dir
1) "dir"
2) "usr/local/bin" 如果在这个目录下存在dump.rdb文件,启动就会自动恢复其中的数据
理论上,默认配置就足够我们使用了。
优点:
1.适合大规模数据的恢复
2.对数据的完整性要求不高
缺点:
1.需要一定的时间间隔进行操作 如果redis意外宕机了,最后一次修改的数据就没有了
2.fork进程的时候,会占用一定的内存空间
将我们所有的命令都记录下来,history,恢复的时候就把这个文件全部在执行一遍!

以日志的形式来记录每个读写操作,将Redis执行过的所有指令记录下来(读操作不记录),只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
重写规则说明
aof默认就是文件的无限追加,文件会越来越大
auto-aof-rewirte-percentage 100
auto-aof-rewirte-min-size 64mb
如果aof文件大于64m。就会fork一个新的进程来讲我们的文件进行重写。
AOF保存的是appendonly.aof文件
appendonly 默认是不开启的。我们需要手动配置 改为yes就开启了aof
重启redis就可以生效
如果aof文件有错误,这个时候redis是启动不起来的,我们需要修复aof文件
redis给我们提供了一个工具 redis-check-aof --fix
如果文件正常,重启就能恢复。
优点:
1.每次修改都同步,文件会更加的完整
2.每秒同步一次,可能会丢失一秒的数据
3.从不同步,效率最高的
缺点:
1.相对于数据文件来说,aof远远大于rdb,修复的数据速度低
2.aof的运行效率也比rdb慢,所以我们redis默认的配置就是rdb持久化