Redis持久化

1. 背景

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

2. RDB (Redis DataBase)

1. 详解

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

• Redis会单独创建( fork)这样一个个子进程来进行持久化,会先将数据写入到一一个临时文件中,待持久化过程都结束了,再用这个临时文件替换_上次持久化好的文件

• 整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能

• 如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效

• RDB的缺点是最后一-次持久化后的数据可能丢失

• 我们默认的就是RDB,一般情况下不需要修改这个配置

• rdb默认保存的文件是 dump.rdb

• 

• 触发机制

  • save的规则满足的情况下,会触发 rdb 规则
  • 执行flushall 命令,产生dump.rdb文件,但是里面是空的
  • 手动触发
    • save : 该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止
    • bgsave : 执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短

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

• 如果要恢复rdb文件

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

• 查看 redis 启动目录

  • config get dir
    

  • 

  • 如果在整个目录下存在 dump.rdb 文件,启动就会自动恢复其中的数据

2. 优缺点

1. 优点

• 适合大规模的数据恢复
• 对数据的完整性要求不高,可以使用

2. 缺点

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

3. AOF(Append Only File)

1. 详解

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

• 以日志的形式来记录每个写操作,将Redis执行过的所有指令记录下来(读操作不记录),只许追加文件但不可以改写文件

• aof保存的是 APPendonly.aof文件

• 默认是不开启的,我们要手动开启

• 

• 重写的规则,一般保持默认即可

• 重写规则说明: 如果 aof 文件大于 64m,太大了! fork一个新的进程来将我们的文件进行重写

  • 首先从数据库中读取键现在的值，然后用一条命令去记录键值对，代替之前记录该键值对的多个命令

• 

• 如果aof文件有错误,Redis是无法启动的!

• 我们需要修复aof文件,Redis给我们提供了这样一个工具 redis-check-aof,命令如下

  • redis-check-aof --fix appandonly.aof
    

• AOF 保存的是命令,所以可以用vim读取,RDB文件是日志,我们无法直接读

2. 优缺点

1. 优点

• 每一次修改都同步,文件的完整性更加好
• 默认开启的是每秒同步一次,可能会丢失这1s的数据

2. 缺点

• 相对于数据文件来说,aof远远大于rdb,修复的速度也比 rdb 慢
• aof运行的速度比rdb慢,所以我们redis默认的配置就是rdb持久化!

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!