云倾万里

无人问津的港口,总是开满鲜花

0%

Redis的两种持久化机制

Redis有两种持久化方案

Redis持久化

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

RDB(Redis DataBase)

持久化快照保存过程

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

Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,在用这个临时文件替换上次持久化好的文件,整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能,如果需要进行大规模数据的恢复,且对于数据库恢复的完整性要求不是很高,那RDB方式要比AOF方式更加高效,RDB的缺点是最后一次持久化的数据可能丢失,我们默认的就是RDB,一般情况下不需要修改这个配置。

触发机制:

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

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

如何恢复rdb文件?

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

  2. 查看需要存放的位置

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

优点:

  1. 适合大规模的数据恢复
  2. 对数据的完整性要求不高

缺点:

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

AOF(Append OnlyFile)

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

默认的不开启的,我们需要手动进行配置,。只需要将appendonly改为yes

如果appendonly.aof被修改的话,可以使用redis-check-aof修复,

1
redis-check-aof --fix appendonly.aof

优点和缺点

1
2
3
# appendfsync always  # 每次修改都会sync,消耗性能
appendfsync everysec # 每秒执行一次sync,可能会丢失1s的数据
# appendfsync no # 不执行sync,这个时候操作系统自己同步数据,速度最快

优点:

  1. 每一次修改都同步,文件的完整会更加好
  2. 每秒同步一次,可能会丢失一秒的数据
  3. 从不同步,效率最高的

缺点:

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

Welcome to my other publishing channels