如何让 Redis 更持久？本文教你！

比眉伴天荒 2022-09-14 03:14 134阅读 0赞

**点击关注公众号，Java干货****及时送达**![cb86d3b6fea44cf0161db2a204492597.png][]

最近在面试的路上愈走愈远了，`Redis`肯定是一个热门面试方向。像有几种数据结构？如何实现延迟队列？淘汰机制是怎么样的？都快问到麻木，这些问题还常绕脑梁。那我们这篇就举一个比较常见且难度适中的面试题来聊聊。**Redis** 的持久化策略是怎么样的？

开局问个问题，相信被问到 **Redis 持久化** 的同学肯定不在少数，答对的同学肯定也不在少数，有些小伙伴说到 **Redis持久化** 肯定张口就来，毕竟也就 **AOF 和 RDB** 两个概念，只要你准备了面试，就不会被问的太惨。

但是你是真的懂还是只是为了应付面试而去应付记忆？你知道 **AOF** 和 **RDB** 两个词是什么单词的缩写吗？你落地实施过吗？你真以为面试官听不出来你是背题还是实操吗？

如果 4 个问题你中了一半，那不妨往下看看，也许会有些收获，起码答面试题的时候心中有小菜~！

![eebcbbb0754e637e5b0df3c7afc23c54.png][]

#### Redis 持久化 ####

> 什么是Redis持久化？

咱们先别记得往解决方向前行，先明白这道题的意思。

*持久化* 就是要让数据永久的保存下去。那什么是 *Redis 持久化* ？那就是把Redis保存在内存的数据写到磁盘中，防止服务宕机了内存数据丢失问题。那有些小伙伴就说了，那磁盘损坏了，数据怎么持久化？就算多点备份能解决磁盘损坏问题，那如果来个多点丢失怎么整？停住停住，咱们这篇讲的是Redis内存数据->磁盘的持久化问题，可别指望靠这个问题跟面试官扯半个小时~！

咱们这篇从几个点来说明 **Redis持久化** 问题。

![67122a94a5ca7b2c476388abe08c2634.png][]

也就三点大的方向，三步走战略解决你的持久化问题。

### 一、RDB ###

先来解决开局的问题之一，**RDB** 是什么单词的全称。RDB（**`R`edis** **`D`atabase** **`B`ackup file**）--- Redis 数据备份文件，也称为 Redis 数据快照。

这个玩意就是用来将内存中的所有数据都记录到磁盘中，当 **Redis** 实例故障重启后，从磁盘读取快照文件，从而恢复数据。内心狂喜，看来学的第一个概念就可以解决 **Redis** 持久化问题~

在学 **RDB** 之前，我们先明白两个核心概念 `fork` 和 `cow`，下面我们会解释，这里先卖个关子。

**RDB** 是 Redis 中默认的持久化机制，按照一定的时间将内存中的数据以快照的方式保存到磁盘中，它会产生一个特殊类型的文件 `.rdb` 数据文件，同时可以通过配置文件中的 save 参数来定义快照的周期.

![5b2da7d584f2b1c5364cf4d2fc388232.png][]

我们从配置文件中的两个配置参数入手，首先是 `save` 配置。

这个指令是由 **Redis** 主进程来执行RDB，会阻塞所有命令

![cc591670b2bb980c7f49028f764add1a.png][]

我们在配置文件中找到有关于 **sava** 的配置

1、

dbfilename dump.rdb

该配置项的作用便是用来定义 **rdb 文件名**（需要注意该名称不能定义为路径，只能定义为文件名称）

当我们执行完 `save` 命令后，便可在 **redis** 文件夹中看到一个 `dump.rdb`   文件

![3a14724d756fe86feac957e38f87a868.png][]

2、

save <seconds> <changes>

该配置项的作用是用来定义多长时间内发生多少次变化便会执行 **bgsave**，如果是 `save ""` 则表示禁用 **RDB**。

我们接下来打开 **save 配置**进行测试

dbfilename dump-test.rdb  # 文件名为 dump-test.rdb
    save 3600 1  # 在 3600 秒内发生一次更改，便会执行 bgsave

我们通过 `redis-cli` 进入操作

![0465448be6acfffd97ac344b9ce919b2.png][]

然后我们退出后便可在当前目录下看到刚刚生成的 *`dump-test.rdb`* 文件

![792e0b5d9d4862d7ac80bb5a9fc2a808.png][]

说明我们配置是生效的，接着我们直接重启 **Redis** ，看是否还存在我们刚刚保存的数据

![e4ab08ab87c499d8bf607fcdfea47e4c.png][]

看到我们的数据，就说明 redis 持久化成功了。然后我们把刚刚生成的  *`dump-test.rdb`* 文件删除后重启 **redis**

![ca5ee42d2c264484e074657d3a2565b8.png][]

这可以说明**Redis** 启动时是靠 **.rdb** 来恢复文件数据的。那我们上面一直说到的 `bgsave`，那 `bgsave` 又是如何执行的呢？

我们在前面有说过两个概念 `fork` 和 `cow`，不知道是否还有印象，这两个概念便是关键~！

`bgsave` 开始的时候会 **fork** 主进程得到一个新的子进程，而 **子进程** 是 `共享` 主进程的内存数据的。子进程会将数据写到磁盘上的一个临时的 `.rdb` 文件中，当子进程写完临时文件后，会将原来的 `.rdb`文件替换掉。这个就是 **fork** 的核心，那什么是 **cow** 呢？**cow** 全称 `copy-on-write` 技术，当主进程执行读操作的时候是访问共享内存的，而主进程执行写操作的时候，则会拷贝一份数据，执行写操作。

具体流程如下：

![42263f3c7a9bdfd715281e50819ac458.png][]

这种持久化方式有什么优点呢？

*  方便持久化，只有一个 `dump.rdb` 文件
 *  容灾性好，可以将文件保存到安全的磁盘中
 *  性能最大化，**fork** 子进程来完成写操作，让主进程继续处理命令，将 **IO** 最大化，保证 **Redis** 的高性能

缺点也是有的：

*  数据安全性低，**RDB** 是间隔一段时间来持久化 （save） ，如果持久化期间 **Redis** 发生故障，那么就会造成数据丢失，所以这种方式适用于数据要求不是很严谨的情况下使用
 *  保存时间长，如果数据量很大，保存快照的时间就会很长，会占用磁盘空间

**优劣均沾，斟酌使用**

**点击关注公众号，Java干货****及时送达**![424121790fa259fc56b2997ce66f66b4.png][]

### 二、AOF ###

**AOF** 全称 **`A`ppend** **`O`nly** **`F`ile** (追加文件)。作用便是 **Redis** 处理的每一个写命令都会记录在 **AOF** 文件中，可以看做是命令日志文件。

该功能默认是关闭的，我们可以在 `redis.conf` 文件中查看有关于 **AOF** 相关的配置项

1、

appendonly yes   # 开启 AOF 日志记录功能，默认是关闭的

2、

appendfilename "appendonly.aof"  # AOF 文件的名称

以上两个配置项便是用来开启 **AOF** 日志记录，那么还有个额外的配置项也需要了解

3、

appendfsync everysec   # AOF 命令记录的频率

该配置项有三个可选值

<table> 
 <thead> 
  <tr> 
   <th>配置项</th> 
   <th>刷盘时机</th> 
   <th>优点</th> 
   <th>缺点</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>Always</td> 
   <td>同步刷盘</td> 
   <td>可靠性高，几乎不会丢失数据</td> 
   <td>性能影响较大</td> 
  </tr> 
  <tr> 
   <td>everysec</td> 
   <td>每秒刷盘</td> 
   <td>性能适中</td> 
   <td>最多丢失1秒的数据</td> 
  </tr> 
  <tr> 
   <td>no</td> 
   <td>操作系统控制</td> 
   <td>性能最好</td> 
   <td>可靠性较差，可能丢失大量的数据</td> 
  </tr> 
 </tbody> 
</table>

有了解 **Mysql** 中 **relay log** 日志的同学，就不会对这种模型很陌生。

原理：它是将写命令追加到 AOF 文件的末尾，使用 **AOF** 持久化需要设置同步选项，从而确保写命令同步到磁盘文件上的时机，这是因为对文件进行写入并不会马上将内存同步到磁盘上，而是先存储到缓存区中，然后由操作系统决定什么时候同步到磁盘。

我们开启 AOF 记录功能查看下：

![519ac7eedafe00c64f424c8c44a85d16.png][]

可以看出我们的每一个操作都已经记录到 **AOF 文件中**，我们这边通过重启 **Redis** 也一样能获取到刚刚存储的数据，说明持久化是有生效的~

如果你还在到处找面试题，不如上这个Java面试库面试小程序。

![b38ff7d3d2f343dcc75090e148b5480d.png][]

我们看到上面的 **AOF** 记录文件是不是觉得很规整？但是在线上环境中越规整反而不好，因为这文件主要是给机器看的，而不是跟我们看的，因此我们最好能够进行压缩。

为了解决AOF文件体积不断增大的问题，用户可以向**Redis**发送 **bgrewriteaof**命令，这个命令会通过 **通过移除AOF文件中的冗余命令** 来重写（rewrite）**AOF**文件，使**AOF**文件的体积变得尽可能地小。**bgrewriteaof**的工作原理和 **bgsave** 创建快照的工作原理非常相似：**Redis**会创建一个子进程，然后由子进程负责对AOF文件进行重写。因为AOF文件重写也需要用到子进程，所以快照持久化因为创建子进程而导致的`性能问题和内存占用问题`，在AOF持久化中也同样存在。

既然存在手动触发压缩，那也存在自动触发压缩，这就得说到配置文件中的两个配置项

auto-aof-rewrite-percentage 100
    auto-aof-rewrite-min-size 64mb

该配置项的意思为当AOF文件的体积大于64MB，并且AOF文件的体积比上一次重写之后的体积大了至少一倍（100%）的时候，Redis将执行**bgrewriteaof**命令。

总结下，它的优点如下：

*  数据安全。AOF 持久化可以配置 **appendfsync** 属性中的 `always`，每进行一次写命令操作就会记录到 **AOF** 文件中一次
 *  一致性。通过 append 模型写文件，即使中途服务器宕机，也可以通过 `redis-check-aof` 工具来解决数据一致性问题

缺点如下：

*  **AOF** 文件比 **RDB** 文件大，而且恢复速度慢
 *  数据集大的时候比 **RDB** 文件启动效率低

同样是优劣均沾，斟酌使用

### 三、两者区别 ###

分别介绍了两者，我们回顾一下两者有什么区别？

<table> 
 <thead> 
  <tr> 
   <th>方面</th> 
   <th>RDB</th> 
   <th>AOF</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>持久化方式</td> 
   <td>定时对整个内存做快照</td> 
   <td>记录每一次执行的命令</td> 
  </tr> 
  <tr> 
   <td>数据完整性</td> 
   <td>不完整，两次备份之间会丢失</td> 
   <td>相对完整。取决于刷盘策略</td> 
  </tr> 
  <tr> 
   <td>文件大小</td> 
   <td>会有压缩，文件体积小</td> 
   <td>记录命令，文件体积很大</td> 
  </tr> 
  <tr> 
   <td>宕机恢复速度</td> 
   <td>很快</td> 
   <td>慢</td> 
  </tr> 
  <tr> 
   <td>数据恢复优先级</td> 
   <td>低，因为数据完整性不如AOF</td> 
   <td>高，因为数据完整性更高</td> 
  </tr> 
  <tr> 
   <td>系统资源占用</td> 
   <td>高，大量CPU和内存消耗</td> 
   <td>低，主要是磁盘IO资源。且 AOF 重写时会占用大量CPU和内存资源</td> 
  </tr> 
  <tr> 
   <td>使用场景</td> 
   <td>可以容忍数分钟的数据丢失，追求更快的启动速度</td> 
   <td>对数据安全性要求较高</td> 
  </tr> 
 </tbody> 
</table>

看完上面后，想必对两种持久化机制都有一定的了解了。两者都有优劣势，那我们该如何选择？这里给出几点意见~

1.  如果可以忍受一小段时间内的数据丢失，可以使用 **RDB**  机制，定时生成 **RDB** 快照， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快
2.  但是如果单单使用 **RDB** 机制，可能导致丢失很多数据，因此我们需要综合使用 **AOF** 和 **RDB** 两种持久化机制，用 **AOF** 来保证数据不丢失，作为数据恢复的第一选择；用 **RDB** 来做不同程度的冷备份，在 **AOF** 文件都丢失或损坏不可用的情况下，可以使用 **RDB** 来进行快速的数据恢复
3.  我们可以利用 **RDB** 来快速恢复数据，并用 **AOF** 来补全数据

我们到这里就讲述了 **Redis** 持久化机制的配置，通过这篇文章的学习，我相信到时候面试的时候遇到这个问题也不至于那么手足无措~！另外，关注公众号Java技术栈，在后台回复：面试，可以获取我整理的 Java 、Redis 系列面试题和答案，非常齐全。

![9eea9a941b6824e6db8e7ed600400565.gif][]

![db53af53f493dea3717c299ce44690ce.png][]

[![2d61a1d3c9db603cde8863791d119730.png][]][2d61a1d3c9db603cde8863791d119730.png 1]

[![1bc0e07e6afbb2a29db49326bd38ba0c.png][]][1bc0e07e6afbb2a29db49326bd38ba0c.png 1]

[![7c04200c0a610079c59de1522920334a.png][]][7c04200c0a610079c59de1522920334a.png 1]

[![e518c256e7a59ae70c1872b3a73f63c3.png][]][e518c256e7a59ae70c1872b3a73f63c3.png 1]

[![67f24f6ff781e8ab3779931e5ac0b994.png][]][67f24f6ff781e8ab3779931e5ac0b994.png 1]

**关注Java技术栈看更多干货**

![4d0b8f63d94edf8e3022e0d992e43979.png][]

![a89082b73ad4b5954f84d0e199421ed8.gif][]

获取 Spring Boot 实战笔记！

[cb86d3b6fea44cf0161db2a204492597.png]: /images/20220828/ed4cdd4be7ad4ef289879a56d9334d65.png
[eebcbbb0754e637e5b0df3c7afc23c54.png]: /images/20220828/ca935320437e4472bdff9a3cc083816d.png
[67122a94a5ca7b2c476388abe08c2634.png]: /images/20220828/8d9cb73360eb49a6862dc5f452f9c918.png
[5b2da7d584f2b1c5364cf4d2fc388232.png]: /images/20220828/72ce73bb573b4a929660c5b4e15920b3.png
[cc591670b2bb980c7f49028f764add1a.png]: /images/20220828/1823ca0bb89b4525b9affe10c8e32f56.png
[3a14724d756fe86feac957e38f87a868.png]: /images/20220828/886ab847ff4f43288d30daf65b024025.png
[0465448be6acfffd97ac344b9ce919b2.png]: /images/20220828/391a8e2954694e60a53b0fd9762045b8.png
[792e0b5d9d4862d7ac80bb5a9fc2a808.png]: /images/20220828/2f105d55fc3343f982e68fb4b007ebc2.png
[e4ab08ab87c499d8bf607fcdfea47e4c.png]: /images/20220828/d091923ac74c4a50ab8029e44163f2f7.png
[ca5ee42d2c264484e074657d3a2565b8.png]: /images/20220828/dd234678d30b43ad9ac630bb1805c8c2.png
[42263f3c7a9bdfd715281e50819ac458.png]: /images/20220828/ab5ee59c2fe64acfb85f7be6e7f8292b.png
[424121790fa259fc56b2997ce66f66b4.png]: /images/20220828/8df4ea053aea40c3a0d1aa9d5572af06.png
[519ac7eedafe00c64f424c8c44a85d16.png]: /images/20220828/c171bec5fe5d4dfcb8483503e42d4648.png
[b38ff7d3d2f343dcc75090e148b5480d.png]: /images/20220828/c2ea84e603ea43f784daa2952b072809.png
[9eea9a941b6824e6db8e7ed600400565.gif]: /images/20220828/dbc12927868243cb80b48a9da7c5044a.png
[db53af53f493dea3717c299ce44690ce.png]: /images/20220828/6e6a4981f45c4c3faf35a67cc31c98a3.png
[2d61a1d3c9db603cde8863791d119730.png]: /images/20220828/38c249a99439483ab370a10f42594e90.png
[2d61a1d3c9db603cde8863791d119730.png 1]: https://mp.weixin.qq.com/s?__biz=MzI3ODcxMzQzMw==&mid=2247539795&idx=1&sn=1efca511169265e8146e90db220159d5&scene=21#wechat_redirect
[1bc0e07e6afbb2a29db49326bd38ba0c.png]: /images/20220828/c2fec115746343dd81392c9eeac1b87f.png
[1bc0e07e6afbb2a29db49326bd38ba0c.png 1]: https://mp.weixin.qq.com/s?__biz=MzI3ODcxMzQzMw==&mid=2247542231&idx=1&sn=75ab147414255cc18c26b03746833be8&scene=21#wechat_redirect
[7c04200c0a610079c59de1522920334a.png]: /images/20220828/86621aca0ce24ba9b0a8ea14e18a024a.png
[7c04200c0a610079c59de1522920334a.png 1]: https://mp.weixin.qq.com/s?__biz=MzI3ODcxMzQzMw==&mid=2247540613&idx=2&sn=acbe3189c3e5d11419b8f383f36b145f&scene=21#wechat_redirect
[e518c256e7a59ae70c1872b3a73f63c3.png]: /images/20220828/343d24198bce4c639d9a59ad2a578bc7.png
[e518c256e7a59ae70c1872b3a73f63c3.png 1]: https://mp.weixin.qq.com/s?__biz=MzI3ODcxMzQzMw==&mid=2247537730&idx=1&sn=3869e164e482b838671fa8896cb33cdb&scene=21#wechat_redirect
[67f24f6ff781e8ab3779931e5ac0b994.png]: /images/20220828/913174b1a2c64a4ca2785d34e2db8f37.png
[67f24f6ff781e8ab3779931e5ac0b994.png 1]: https://mp.weixin.qq.com/s?__biz=MzI3ODcxMzQzMw==&mid=2247540947&idx=1&sn=a4941f93acb4ee551534a4a1f57d9376&scene=21#wechat_redirect
[4d0b8f63d94edf8e3022e0d992e43979.png]: /images/20220828/6e310be4220b4f439762e5d196b606db.png
[a89082b73ad4b5954f84d0e199421ed8.gif]: /images/20220828/c048ddafcf464bd2881c9e787eece7f8.png