前言

redis的十大类型终于告一段落了,下面我们开始redis持久化新篇章

为啥需要持久化呢?

我们知道redis是挡在mysql前面的带刀侍卫

是在内存中的,假如我们的redis宕机了,难道数据直接冲入mysql???

这显然是不可能的,mysql肯定扛不住这样的场景,所以我们有了redis持久化策略

实际上redis是可以使用rdb和aof混合策略的

但是在本篇博客中笔者先单独谈论rdb,以及一点点的源码分析

再考虑aof的情况

废话不多说,现在我们开始今天的内容吧

RDB

主动触发

rdb主要作用是指定时间内写入硬盘,在恢复的时候全部写入内存

生成的文件叫做dump.rdb 我们可以在conf文件中修改其的保存规则

默认的规则如下

这里分为redis6.0.16以前和6.2以后

6.0.16 保存规则是

900s 至少一次修改

300s 10w次修改

60s 1w次修改

6.2以上版本是

3600s 1次

300s 100次

60s 1000次

注意:这里的参数不太好理解,官网的表述也是含糊其辞的

为了方便测试 我们修改成5秒至少两次修改,用于查看情况

可以使用vim编辑器对conf文件进行编辑

我们还可以对生成的dump文件名以及路径进行修改方便观察

这里是尝试过了忘记截图了

我们直接说结论:

在五秒内执行两次写操作,dump文件会进行更新

在五秒外 甚至十秒内写入两次也是会更新的,笔者查阅资料未果,于是开始阅读源码

最终是在server.c的serverCorn函数中发现

这里我们就能发现大于我们设置的时间 也是ok的

下面我们不做过多测试,具体可以自行进行测试

注:记得开两个服务端,一个在linux一个在redis方便查看对应的文件大小变化

以上四redis的主动调用

下面我们来说说redis的rdb的手动保存

这里我们修改完config文件箱查看是否生效可以使用config get/set 属性来查看

手动触发

主要是两个命令

save 和 bgsave

save指令是不可以使用的因为如果使用就会直接阻塞,直到保存完成再允许用户线程再访问

bgsave则是fork一个子进程来完成rdb文件的快照服务,不进行阻塞

生产上是万万不能使用save来保存快照的

优缺点

下面我们谈谈rdb的优缺点

优点:

文件非常紧凑,非常适合备份文件,一把抓,适合灾难恢复

最大限度提高了redis的性能,子进程制度则rdb,父进程负责读写数据

缺点:

可能会丢失最近一次修改的数据,因为还没有达到保存快照的条件

在数据量比较庞大的时候,子进程也会很耗时,且非常影响服务器的性能

检查和修复rdb文件

假设我这里随便在rdb文件后面添加一串乱码

此时redis服务器重启的时候就无法成功

我们需要找到这个文件夹中使用修复工具

此时就修复成功了

出现rdb快照的情况

注:禁用rdb快照 在设置的时候直接设置save ""即可

rdb优化配置项

1.stop-write-on-bgsave-error yes 默认为yes,快照写入 失败的时候,直接停止,保证数据一致性

2.rdbcompression yes 压缩,占用空间大了只保存最后一次修改的结果

3.rdbchecksum 算法校验可靠性   类似于之前tcp那块的校验和算法

4.rdb-del-sync-files 复制实例的时候没有指定持久化的直接删除,默认为no

AOF 

我们刚刚说了RDB,那么为啥还需要一个AOF呢

他的诞生就是为了解决rdb可能直接丢失一次最近写入的数据,因为不满足保存快照的条件

注意 redis默认是不打开aof的,需要设置

appendonly  设置为yes即可

主要做的事情就是以日志形式保存设置的命令,在重启的时候直接重新执行一遍

下面我们介绍一下aof执行的流程

三种写回策略:

Always    写一条备份一条

everysec   每秒进行备份

no             不自己备份,靠操作系统决定啥时候写回

文件说明

文件以前是和rdb放一块的,现在放在dir下面

在redis6之前是以appendonly.aof保存

现在是以三个文件混合保存

分别是 base   incr    清单文件

每次写入先放到incr增量文件中

incr文件可能存在多个,base文件只有一个

异常恢复

使用redis-check-aof --fix

优缺点

优点:

默认一秒写回,最多丢失一秒的数据

写一半断了也可以使用恢复策略

可以轻松导出文件,可读性强

假设我flushdb了   只要没继续进行写操作,是可以修改aof文件救回来的

缺点:

等效文件大于rdb,恢复速度慢于rdb

aof重写机制

随着aof文件的越来越大,占用空间也就越来越大,需要一定的瘦身计划

所以在达到一定的峰值之后会进行内容压缩

也就是假设我这里对k1进行了三次的设置

只会保存最后一次的更改

混合机制

两者共存的时候默认先加载aof,但是默认使用rdb

aof是老大