【Redis】RDB和AOF

Redis是内存数据库,如果不将内存中的数据库状态保存到磁盘,那么一旦服务器进程退出,服务器中的数据库状态也会消失。所以Redis提供了持久化功能!

RDB(Redis DataBase)

在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里。

Redis会单独创建(fork )一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何I0操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

在这里插入图片描述

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nPtPmmzM-1600050464511)(C:\Users\黄良帅\AppData\Roaming\Typora\typora-user-images\1600045219494.png)]

900秒1次

300秒10次

一分钟1W次

save 60 5 主要我们在60s内修改了5次,就会触发生成dump.rdb文件

触发机制

  1. save的规则满足的情况下,会自动触发rdb规则
  2. 执行flushall命令,也就是触发我们的rdb规则
  3. 退出redis,也会产生一个rdb文件

备份就自动生成了一个dump.rdb

如何恢复rdb文件

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

  2. 查看需要存在的位置

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

优点:

  1. 适合大规模的数据恢复,dump.rdb
  2. 对数据的完整性不高

缺点:

  1. 需要一定的时间间隔进程操作,如果redis意外宕机,最后一次记录就没有了
  2. fork进程的时候,会占用一定的内存空间

AOF(Append Only File)

将我们的所有命令都记录下来,history,恢复的时候就全部再执行一遍

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

AOF保存的是appendonly.aof文件

  1. 默认不开启、手动开启,重启生效
  2. 可以自己选择生成文件的名字

每一秒写一次

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BGqKq4Um-1600050464516)(C:\Users\黄良帅\AppData\Roaming\Typora\typora-user-images\1600046440315.png)]

万一appendonly.aof出错怎么办?

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lx6q9koM-1600050464520)(C:\Users\黄良帅\AppData\Roaming\Typora\typora-user-images\1600046729742.png)]

导致启动不了我们的Redis

解决方法

利用我们的Redis-check-aof --fixe

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GW7CvYTC-1600050464523)(C:\Users\黄良帅\AppData\Roaming\Typora\typora-user-images\1600046658253.png)]

如果我们的aof大于64M,就会fork一个新的进程来将我们的文件进行重写

优点:

  1. 每一次修改都同步,文件的完整会更加的好
  2. 默认开启的是每秒同步一次
  3. 从不同步,效率是最高的

缺点:

  1. 相对于数据文件来说,aof远远大于rdb的内存,修复的速度也比rdb慢
  2. aof运行效率要比rdb慢,所以说redis默认的配置是我们的rdb持久化

扩展

在这里插入图片描述

猜你喜欢

转载自blog.csdn.net/qq_40915439/article/details/108574111