Redis持久化详解，结合图解（面试，工作都用得到）

最新推荐文章于 2024-10-18 13:42:20 发布

还不快去敲代码啊

最新推荐文章于 2024-10-18 13:42:20 发布

阅读量461

点赞数 1

分类专栏： redis 文章标签： redis

本文链接：https://blog.csdn.net/qq_42865087/article/details/109499252

版权

redis 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

说到持久化，大家可能第一个想到的就是数据库层面的持久化，做了持久化就算数据库服务器宕机，重启之后，数据也还是不会丢失。可以说是很奈斯的了。
但是今天我们要了解的是Redis层面的持久化，说起Redis，可能大家第一印象就是，不就是缓存吗？这个还有持久化这么一回事吗？缓存不是放在内存当中的吗？
Redis服务器出问题，重启不就好了吗？就算缓存丢了，重新查一遍数据库然后再设置到Redis就好了呀。感觉这个Redis持久化，存不存在好像也没什么问题呀？
可能少数同学会有一些这样的疑问，因为我第一次听到Redis持久化，其实脑海当中也是浮现了这么多的问题。
没关系，接下来就让我们带着困惑，来一起去了解Redis的持久化带给我们的好处，以及他是如何去实现持久化的。

一、Redis需要持久化的原因

举个很简单的例子，现在的互联网公司，内部的架构基本都是采用微服务化，分布式的架构进行部署了。分布式带来的好处是数之不尽的。其中最常见的就是利用Redis作为缓存，部署在应用与数据库交互之间，存储一些较为常见的查询数据，减轻数据库的并发压力。假如，某一时刻Redis服务器出现了问题，缓存的大量数据全部丢失，那么这个时候即使你重启了Redis服务器，所有的查询动作在这个时候是在Redis里面取不到值的，那么这个时候，这些查询操作都会打入数据库。如果短时间内，高并发的情况下访问数据库，那就麻烦了，轻则数据库堵塞，重则直接把数据库击穿。因为数据库的抗并发能力是远远低于Redis的。
那么这个时候Redis的持久化就发挥作用了，Redis持久化文件可以帮助我们将Redis服务器崩溃前已经缓存好的数据进行备份，在需要的时候可以快速恢复，这样就可以起到快速止血的作用，避免了对数据库造成的高并发问题。

二、Redis持久化的方式

Redis持久化方式有三种。分别是RDB快照、AOF持久化以及Redis 4.0推出的混合持久化方式。今天就带大家一起来了解一下这三种持久化方式。

1、RDB快照

什么是RDB快照

一句话来描述，就是Redis持久化生成的一种二进制文件，存储的是Redis的缓存数据。

RDB快照开启方式

是否开启RDB快照，就看redis.conf（这个文件我们解压redis安装包就可以看到）文件里面的这一块配置。如果save策略开启了，那么我们可以认为开启了RDB快照持久化方式。（注意RDB文件是二进制文件）
在这里插入图片描述
save是一个动作，即Redis将当前内存的缓存数据写入持久化文件
那么这里save后面的两个值又是什么意思呢？
拿第一个save 900 1来说，在900秒之内如果至少有一个key发生了变化，那么就做一次save持久化动作。
这里写了三种save，也就意味着有三种save的持久化策略，只要任意满足其一，都会触发save动作。

RDB快照持久化文件命名及存储位置

在这里插入图片描述
例如

同时，值得注意的一点是，rdb文件的名称跟生成位置，在重启redis之后，也将是redis作为数据重启的一个依据。在RDB快照模式下，重启redis将会去配置的相应路径下寻找RDB持久化文件进行快速恢复，这是redis自动会去做的事情。

RDB快照持久化方式的弊端

看完上面的RDB快照的持久化策略，我想大家应该都能猜的到了。只有在满足持久化策略的情况下，Redis才能进行持久化，假如在还没满足策略的前提下，Redis发生了问题，导致缓存丢失，那么这个时候，是没有持久化文件进行备份和数据恢复的。
有同学可能会说，那save策略设置成只要一秒有一次不就好了吗？
这么跟你说吧，你的Redis你会给他分配多少内存去做缓存？假设只有几个G的话，那你每秒都去做一次几个G的备份，那Redis的大部分资源都要消耗在持久化上面了，并发能力就肯定会下降，我想这个肯定不是你想看到的。

save与bgsave

RDB快照持久化动作可以是save或者是bgsave。但是两者之间是有差别的。
这里用一张图来做对比描述。
在这里插入图片描述
这里还要补充的一点是，bgsave是有写时复制机制的。简单来说就是，当执行bgsave动作时，客户端还有写入缓存的命令发过来时，redis在生产RDB快照的同时，也可以处理读跟写入的命令，不会发生堵塞。如果是读命令，子进程跟主进程互不影响，如果是写命令，那么这块数据就会被复制一份，生产该数据的副本，而修改生成的副本，子进程也会将其写入到持久化文件当中。

2、AOF

什么是AOF

Redis持久化生成的持久化文件，生产的是传入redis服务器的指令。包含指令的命令，key还有value。

如何开启AOF持久化方式

话不多说，先放个图大家就明白了
在这里插入图片描述

AOF相对于RDB的优势

基于RDB快照的劣势，也就是生产持久化文件的苛刻条件可能会导致在生产持久化文件之前，数据全部丢失。在redis 1.1版本开始，redis采用了一种可以说是完成耐久的持久化方式。也就是我们的AOF持久化方式。为什么说他完全耐久呢？
因为他针对RDB的短板，采取了另外一种策略

策略模式	策略说明	优点	缺点
appendfsync always	每写入一条指令，就将指令记录到AOF文件（先写入os cache，之后再同步到磁盘）	安全性高，几乎不会丢失缓存数据	性能太低，每条命令都去写入太耗费性能
appendfsync everysec	每隔一秒，就将写入的指令记录到AOF文件	性能较好，并且足够快	安全性相对于always较低，可能会丢失一秒的缓存数据。
appendfsync no	不去控制写入AOF文件的策略，采取让操作系统自行控制的方式	性能非常之快	安全性低，将同步方式交给操作系统去决定

可以说appendfsync always与appendfsync everysec几乎可以是完全耐久的策略了，最多只会丢失一秒的缓存数据，这个量相对来说影响就比较小了。

如果选择AOF持久化，这里推荐使用的是appendfsync everysec的持久化方式，在性能跟安全方面都相对于更均衡一些。

AOF重写机制

AOF还有一个可以开启的比较好的机制，那就是重写机制。
为什么要开启AOF重写呢？因为AOF持久化方式会记录太多没有用的命令，这一些命令可以被redis内部通过AOF重写给优化掉。
什么是重写机制呢？我给大家看个例子。
在说重写机制前，我先带大家看一下AOF文件存储的是一些什么样的内容。
在这里插入图片描述

知道了AOF存储的文件内容以后，我们再来根据一个例子看看，AOF重写又是怎么回事。现在我们的redis缓存当中已经存在了一个user的缓存了。那么我们现在来执行一下这个命令

incr count
执行三次

在这里插入图片描述
再来看看aof的文件内容。

我们之前说过，aof文件恢复redis内存数据的方式是通过执行文件当中的一条一条指令，那么现在你是否发现问题？多个重复incr指令，也被放入了aof文件当中，这样是否给redis的恢复数据带来了压力？如果我的多次incr可以直接变成set count 3，这样是否会更快？答案是一定的。那么我们如何去让他变成set count 3呢？这就要用到重写机制了。
重写机制是在开启AOF之后默认开启的，下面是重写机制的策略信息。
在这里插入图片描述
如果同学们想测试着玩会儿，可以通过bgrewriteaof进行手动重写，这样就可以看到效果啦。