当前位置:   article > 正文

【Redis】理论进阶篇------Redis的持久化_redis持久化

redis持久化

一、前言

     前面学习了Redis的相关的十大数据类型以及用SpringBoot集成我们的Redis的工具代码的书写。从这篇文章开始,就会从Redis相关的一些理论(也是面试和工作的热点知识)如:Redis的持久化、Redis的订阅发布模型、Redis集群环境搭建、哨兵模式等等方面介绍Redis相关的进阶知识。希望对各位小伙伴能有所帮助。

二、Redis的持久化

1、为什么会有Redis的持久化

首先Redis是我们的缓存,是一种内存数据库,如果我们存储数据的时候,不将数据库状态储存到磁盘中,那么服务器一旦宕机、进程出现错误。服务器中的数据也会随之消失。所以为Redis提供持久化的功能是必不可少的!

2、Redis的持久化是什么

官网原话:

上面是官方对Redis持久化做出的解释,我们不难看出Redis的持久化就是将数据写入磁盘。而其中的关键操作其实是RDB与AOF。接下来会其详细展开介绍。

3、RDB

1、什么是RDB

Redis Database用官网的话说就是:在指定的时间间隔内将内存中数据集快照(Snapshot  像照相机那样咔嚓一下)写入磁盘,如果要恢复数据集则将快照文件读取到内存中。

工作流程:redis中会有一个父进程,正常的处理client发出的各种请求,此时如果要触发RDB生成RDB文件,则可以通过配置文件修改触发的操作我们称为自动触发、或则通过save和bgsave指令来手动触发来实现数据备份。此时父进程就会产生(fork)一个子进程来实现持久化,会先将数据写入一个临时文件中,待持久化结束后,再用这个临时文件代替上次持久化好的文件(rdb保存的文件就是一个dump.rdb文件)。整个过程主进程不进行 任何IO操作,确保了极高的性能。

2、RDB的触发

①RDB的自动触发

首先我们找到我们Redis下载的文件目录,我们找到以.conf结束的文件:

打开这个文件找到我们的快照Snapshot 

正如Redis的配置文件所示 save <seconds> <changes>,当我们的时间间隔大于等于设置的seconds,修改次数大于等于changes时,Redis会自动触发RDB,生成对应的dump.rdb文件。

②RDB的手动触发

既然有自动触发,为什么需要手动触发呢。因为自动触发是规定操作内生成dump.rdb文件,但是如果有非常重要的数据需要及时存储,但是又不满足自动触发的需求。这时Redis官方,就为我们提供了save和bgsave两种手动触发的操作来 生成RDB文件。

a.save指令

用户可以通过执行SAVE命令,要求Redis服务器以同步方式创建出一个记录了服务器当前所有数据库数据的RDB文件。而且再持久化完成save指令的整个期间内,Redis都不能处理 其他的命令。SAVE命令是一个无参数命令,它在创建RDB文件成功时将返回OK作为结果。(注:线上禁止使用,不推荐)

b.bgsave

Redis会在后台异步进行拍照操作,不阻塞快照同时还可以响应客户端的请求,该持久化化会fork一个子进程,由子进程复制持久化的过程(父进程与子进程各做各的,会不干扰)。

③总结rdb文件的触发

1:通过我们的各种触发操作,会自动触发rdb规则;

2:除了以上,执行flushdb/flushall命令,也会触发rdb规则(为了保证数据的完整性,但是文件里面是空白的);

3:退出redis,也会产生rdb文件。

4:主从复制时,主节点自动触发。

3、RDB的恢复

从以下方面恢复数据

①:只需将rdb文件放在我们Redis的启动目录下,redis启动时候会自动检查dump.rdb文件恢复其数据;

②:物理恢复,一定服务和备份分机隔离。(PS:不可以把备份dump.rdb文件和产生redis的服务器放在同一台机器,必须分开存储,以防生产机物理损坏后备份文件也挂了)

4、AOF

1、什么是AOF

Append Only File用通俗的话来讲:以日志的形式来记录每个写操作,将Redis执行的所以写操作指令记录下来(读操作不记录)。当重启Redis的时候会将新的持久化的日志文件中的数据恢复。

Redis中AOF的操作流程:

①:Client作为命令的操作者,会在redis中不断书写各种指令命令;

②:Redis并不会直接将这些指令命令直接写入AOF文件,而是先写在一个临时的AOF文件中(其实是一个缓冲区)。当这个临时文件的数量足够多时,再写入磁盘,避免了频繁的IO操作;

③:AOF的临时文件会根据三种写回策略(后面解释)将命令写入磁盘上的AOF文件中;

④:当AOF文件中的内容越来越多时,会执行AOF重写,起到AOF文件压缩的目的。

⑤:当Redis重启的时候会将AOF中的数据重新载入。

2、AOF中的常见配置指令

我们像RDB一样,找到AOF的配置文件,介绍相关指令:

1:appendonly no 

默认不开启,我们需要手动进行配置,将"no"->"yes"

2:appendfilename "appendonly.aof"

表示修改的生成的aof文件的名称

3:三种回写策略机制

appendfsync always:同步回写,优:可靠性高,数据基本不丢失;缺:是一个极端,每个命令都要写到磁盘,性能影响大。
appendfsync everysec:每秒回写,优:性能适中;缺:宕机时,丢失一秒类数据。(Redis默认)
appendfsync no:OS控制的回写,优:新能好;缺:也是一个极端,宕机时,丢失数据数据较多。

4:AOF文件重写规则

首先aof默认文件无限追加,这样文件就会越来越大。

同时满足以下的关系,才会触发AOF的重写:

auto-aof-rewrite-percentage 100:根据上次重写后的aof大小,判断当前aof是不是增长了一倍
auto-aof-rewrite-min-size 64mb:如果aof文件大于64M,fork一个子进程来将我们文件进行重写

三、RDB与AOF的各自优缺点

1、RDB

优:

①:适合大规模的数据恢复

②:可以按照业务定时备份

③:对数据完整性和一致性要求不高

④:RDB文件在内存中加载速度比AOF快的多

缺:

①:在一定时间内做一次备份,如果redis出现宕机的话,就会丢失从当前开始的最近一次快照期间的数据

②:内存数据的全量同步,数据量太大,会大量使用IO,影响服务器性能

③:fork子进程的时候,会占用一定空间,需要考虑内存空间的问题

2、AOF

优:

①更好的保护数据不丢失、性能高、可做紧急恢复

缺:

①:在相同数据集下,aof文件要远大于rdb文件,恢复速度慢 

②:aof的效率慢于rdb,所以redis默认的是使用rdb持久化

四、RDB和AOF的混合使用

1、谁的优先级大

我们知道Redis默认使用的是RDB,那么如果将aof与 rdb同时开启,是不是rdb的优先级就更大,先加载RDB文件呢?我们先来看个流程图:

从该图中我们可以看出,如果有aof文件,则先加载aof文件;若没有aof文件而开启了rdb则先加载rdb文件,如果两个都没开启,则该怎么执行就怎么执行。

2、开启RDB与AOF的混合模式

①:开启混合方式

aof-use-rdb-preamble yes(默认是yes)

②:开启结果

PS:前提是开启AOF。

RDB做全量的持久化,AOF做增量的持久化:即先使用RDB进行快照的储存,然后使用AOF持久化做所有写的操作,当重写策略满足或手动触发重写的时候,将最新的数据存储为新的RDB记录。

总的来说最后生成的也是aof文件,但是该文件一部分包含了RDB格式,一部分包含了AOF格式。

如下所示:

五、总结

最后做一个总结,首先博主的这篇博客的记录是学习了b站上up主【狂神说JAVA】、【尚硅谷】的redis学习视频后写的。然后这篇博客也是在以前Redis版本上的基础上结合最新的版本完成的。当然博主自己写的这篇博客也是让我自己对Redis的持久化功能有了更进一步的认识,我个人觉得这篇博客对一些常见的关于Redis的持久化的面试题的回答是涉及的足够的。如果对正在阅读的小伙伴有帮助,不要忘记点赞

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/我家小花儿/article/detail/403583
推荐阅读
相关标签