【Redis持久化】RDB、ROB介绍和使用

引言

持久化的目的，其实就是在Redis重启或者中途崩溃的时候能够依靠自身恢复数据，而不需要再次访问MySQL数据库，重新取得数据，增加MySQL的工作量。

在此有两种方法，RDB和AOF，两种方法都是将从MySQL得到的数据内容进行放置。

ROB：在不同的时间点，将 redis 存储的数据生成快照并存储到磁盘等介质上。
AOF：将 redis 执行过的所有写指令记录下来，在下次 redis 重新启动时，只要把这些写指令从前到后再重复执行一遍（类似于MYSQL数据库的SQL文件），以此实现数据恢复。

首先，介绍ROB定义中的快照（snapshot）：把某一时刻的数据和状态以文件（RDB文件：dump.rdb)的形式写到磁盘上。

ROB特点：

优点：

虽然 RDB 有不少优点，但它的缺点也是不容忽视的。

如果你对数据的完整性非常敏感，那么 RDB 方式就不太适合你，因为即使你每 5 分钟都持久化一次，当 redis 故障时，仍然会有近 5 分钟的数据丢失。

所以，redis 还提供了另一种持久化方式，那就是 AOF。

打开配置文件redis.windows.conf

1、Redis 6.0.16及以下：

在这里插入图片描述

上图内容为：

save 900 1:每隔 900s(15min)，如果有超过1个 key 发生了变化，就写一份新的 RDB 文件。

300 10:每隔 300s(5min)，如果有超过 10个 key 发生了变化，就写一份新的 RDB 文件。

2、Redis 6.0.16以上：

在这里插入图片描述

save：主程序中执行会阻塞当前redis服务器，直到持久化工作完成行save命令期间，Redis不能处理其他命令，线上禁止使用。

bgsave（默认）：Redis会在后台异步进行快照操作，不阻寒快照同时还可以响应客户端请求,该触发方式会fork一个子进程由子进程复制持久化过程。

lastsave：获取最后一次成功执行快照的时间

下图为lastsave的使用方式：
在这里插入图片描述

redis- check- rdb

使用后效果如下：
在这里插入图片描述

配置文件中修改为：save后跟空格，具体结果如下图所示：
在这里插入图片描述

开启：

在redis配置文件redis.windows.conf中：

appendonly yes

注意：

AOF保存的是appendonly.aof 文件
默认的 AOF 持久化策略是每秒钟 fsync 一次（fsync 是指把缓存中的写指令记录到磁盘中），因为在这种情况下，redis 仍然可以保持很好的处理性能，即使 redis 故障，也只会丢失最近 1 秒钟的数据。
如果在追加日志时，恰好遇到磁盘空间满、inode 满或断电等情况导致日志写入不完整，也没有关系，redis 提供了 redis-check-aof 工具，可以用来进行日志修复。

在这里插入图片描述

因为采用了追加方式，如果不做任何处理的话，AOF 文件会变得越来越大，为此，redis 提供了 AOF 文件重写（rewrite）机制，即当 AOF 文件的大小超过所设定的阈值时，redis 就会启动 AOF 文件的内容压缩，只保留可以恢复数据的最小指令集。

AOF 重写的内部运行原理：

在重写即将开始之际，redis 会创建（fork）一个“重写子进程”，这个子进程会首先读取现有的 AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
与此同时，主工作进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的 AOF 文件中，这样做是保证原有的 AOF 文件的可用性，避免在重写过程中出现意外。
当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新 AOF 文件中。
当追加结束后，redis 就会用新 AOF 文件来代替旧 AOF 文件，之后再有新的写指令，就都会追加到新的 AOF 文件中了。