持久化-RDB

Redis database，在指定的时间间隔内，将内存中的数据集快照写入到数据库；恢复的时候，直接读取快照文件，进行数据的恢复

测试代码

  • 进入服务器Redis的默认安装位置找到dump.rdb文件
  • vim 打开redis.conf文件进行编辑，方便测试我们将将原先的规则修改为save 60 3，意思就是 60秒内有三次写入操作就会触发rdb操作，进行持久化保存
  • :wq! 保存配置后退出，我们先手动删除dump.rdb文件
  • 连接redis服务后进行3次写入操作
  • ls 命令查看是否生成了dump.rdb文件
  • 说明在save规则满足的情况下，会触发RDB规则
  • 再次删除dump.rdb文件，图片省略，连接redis服务后执行flushall清空命令
  • ls 命令查看是否生成了dump.rdb文件
  • 说明执行flushall清空缓存的操作，也会触发RDB规则
  • 再次删除dump.rdb文件，图片省略，连接redis服务后执行SHUTDOWN退出命令
  • ls 命令查看是否生成了dump.rdb文件
  • 说明执行SHUTDOWN命令退出Redis操作，也会触发RDB规则**

触发机制（总结）

  • 执行写入操作，save的规则满足的情况下，会自动触发rdb原则
  • 执行flushall命令，也会自动触发我们的rdb原则
  • 执行SHUTDOWN命令退出redis，也会自动触发我们的rdb原则

如何恢复RDB文件(默认的配置)

  • 只需要将rdb文件放到redis启动目录下即可，Redis启动的时候会默认自动检查dump.rdb文件，并恢复其中的数据
  • 查看文件存放的地址
[root@iZ2zedw5vursd09dhzivjnZ redis]# redis-cli
127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin"
  • 当然这个存放的地址我们可以自行修改，vim打开redis.conf文件，找到刚才我们修改save规则的地方，下面就可以看到

工作原理

在进行 RDB 的时候，redis 的主线程是不会做 io 操作的，主线程会 fork 一个子线程来完成该操作；

  • Redis 调用forks。同时拥有父进程和子进程。
  • 子进程将数据集写入到一个临时 RDB 文件中。
  • 当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。

这种工作方式使得 Redis 可以从写时复制（copy-on-write）机制中获益(因为是使用子进程进行写操作，而父进程依然可以接收来自客户端的请求。)

优缺点

  • 优点
  • 启动速度快、适合大规模的数据恢复
  • 对数据的完整性要求不高
  • 缺点
  • 会造成数据的丢失，按照规则配置，如果Redis最后一次宕机了，最后一次修改就没有了
  • fork进程的时候，会占用一定的内存空间, 数据量大的话，可能会造成Redis停止服务几毫秒

持久化AOF

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

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

测试代码

  • Redis默认是开发RDB持久化默认，我们想要使用AOF，需要手动开启，同样vim命令打开redis.conf文件
  • appendonly默认为no, 修改为yes即可
  • 重启Redis服务器
  • 如果使用的是redis7以及以上版本，会发现在原先的目录下多了一个appendonlydir 文件夹
  • 如果使用的是redis6或者之前的版本，那么在目录下会直接在/usr/local/bin/ 目录下生成一个appendonly.aof文件，这和不同版本的redis.conf配置文件有关
    官方解释是：

翻译如下：

#它们是创建和应用的。仅附加文件名由Redis按照特定模式创建。
#文件名的前缀基于“appendfilename”配置参数，后面是有关序列和类型的其他信息。
#例如，如果appendfilename设置为appendonly。aof，以下文件

#可以导出名称：
#-appendonly.aof.1.base。rdb作为基本文件。
#appendonly.aof.1.incr.aof。aof作为增量文件。
#-appendonly.aof。manifest作为清单文件。

appendfilename“appendonly.aof”

#为了方便起见，Redis将所有持久的仅附加文件存储在一个专用的目录。目录的名称由appenddirname确定配置参数

appenddirname“appendonlydir”
  • 现在进入appendonlydir 文件夹， 可以看到有三个文件
  • vim 命令查看appendonly.aof.1.incr.aof文件，这里面存储的都是我们之前操作的命令

修复aof文件

  • 假如这个文件收到损坏，里面被写入了其他数据
  • 现在我们重启Redis会发现，启动失败，连接不上
  • redis给我们提供了一个工具redis-check-aof --fix ，后面跟上我们的aof文件即可
redis-check-aof --fix appendonly.aof.1.incr.aof

redis 持久化文件过大 redis 持久化文件查看_数据库

  • 再次启动Redis服务，启动成功
  • 还有一点需要注意是，aof默认的就是文件的无限追加，文件会越来越大！在配置文件中可以设置文件的大小！
# appendfsync always # 每次修改都会sync 消耗性能
appendfsync everysec # 每秒执行一次 sync 可能会丢失这一秒的数据

auto-aof-rewrite-percentage 100  #写入百分比
auto-aof-rewrite-min-size 64mb  #写入的文件最大值

优缺点

  • 优点
  • 每次修改都会同步记录，文件的完整性会更加好
  • 每一秒同步一次数据，也就意味着可能会丢失这一秒的数据
  • 从不同步，效率最高
  • 缺点
  • 相对于数据文件来说，aof远远大于rdb，修复数据比较慢
  • Aof运行效率也要比rdb慢（IO操作），所以我们redis默认的配置就是rdb持久化

RDB和AOF比较

RDB

AOF

启动优先级

低

高

体积

小

大

恢复速度

快

慢

数据安全性

可能丢失数据

根据策略决定

如何选择使用哪种持久化方式？

一般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。

如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。

有很多用户都只使用 AOF 持久化， 但并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快。