跟我一起学Redis

跟我一起学Redis之Redis持久化必知必会

2020-12-04  本文已影响0人  Code综艺圈

前言

Redis是出了名的速度快，那是因为在内存中进行数据存储和操作；如果仅仅是在内存中进行数据存储，那就会导致以下问题：

对于Redis持久化在工作中和面试过程中是一个很重要的技术点，必用必考，接下来详细说说Redis持久化；

正文

Redis针对数据持久化有两种方案，如下：

两种方式都可以通过配置文件轻松搞定，来，咱们先从RDB开始；

fork：后续会频繁提到，简单解释一下，fork的作用是复制一个与当前进程一样的子进程，该子进程的所有数据都和原进程一致。

RDB持久化

理论放到后面再说，先来看看实际操作，再来做总结；上次对配置文件简单进行说明，这次就直接找到快照那配置就行啦，先看看默认配置：

1

通过 save <seconds> <changes>进行条件配置，如果触发条件就自动进行RDB持久化操作。默认配置中包含以下三种条件，满足其中一个就自动保存数据到磁盘：

测试验证

为了测试时间方便，将其中一个条件改为1分钟内有3个key的值修改了就进行持久化到磁盘，如下：

  1. 先将原有的dump.rdb文件删除掉，避免影响测试效果；

  2. 修改配置文件如下：

    image-20201202124046958

  3. 用修改之后，指定该配置文件重启redis-server，然后开始测试；

    image-20201202125318782

  4. 尝试打开dump.rdb看看，咋一看是看不懂，但其实是有对应关系的，这里就不深究了

    image-20201202181142589

Redis强大吧，不知不觉的就把数据备份，主要是还不影响正常操作，上图中第四步中就有体现，主进程fork了子进程进行备份，主进程不参与备份持久化操作。既然备份文件有了，如何进行恢复数据呢？ redis-server在启动的时候自动将当前目录中的备份文件(dump.rdb)数据加载到内存中；如下图所示：

image-20201202140710879
RDB其他配置项

那为什么是dump.rdb文件？，为什么又是当前目录？，如果rdb备份文件写入失败了怎么办？这些通过配置文件中SNAPSHOTTING部分都有详细的说明，并提供相关配置项进行设置，如下：

RDB手动触发备份

上面说到自动触发备份，其实在实际应用场景中，有些需求很急，如果要求等到满足条件备份完成之后才处理问题，间隔时间短还好点，如果间隔时间超过5分钟，估计等待处理问题的人要上房揭瓦啦；Redis同样为大家考虑到了，提供手动备份的方式，如下：

简单测试一下，删除dump.rdb文件，将配置文件恢复到默认值，然后指定配置文件重启redis-server，如下：

image-20201202150850388
如何停止或禁用RDB快照自动备份

可以通过配置文件的形式配置，也可以通过命令的形式进行关闭，但通过命令的方式，服务器重启之后就失效了，所以一般建议通过配置文件进行配置；

RDB备份流程
image-20201202164228149

简要说明：

  1. 当触发bgsave持久化时(满足配置条件或手动执行bgsave命令)，主进程fork一个子进程进行持久化操作，主进程不参与任何持久化IO操作；

  2. 为了不影响原有rdb文件的使用，子进程会将快照数据先写入到临时文件;

  3. 当快照数据完全备份到临时文件时，就替换掉原有的rdb文件，从而得到最新数据的rdb文件；

    注：当执行sava命令的时候，会导致阻塞，只有等快照数据持久化完成之后，才能做其他事情；

RDB持久化优缺点

每一项技术在解决已有问题的时候，肯定也会带来新问题，RDB用来解决持久化问题，那它有什么优缺点呢？

优点

缺点

AOF持久化

既然已经有了RDB持久化了，那为什么还得出一个AOF呢？从RDB的缺点来看，很大程度上是因为可能会丢失最后一次备份之前的数据，对于一些重要数据来说，是不能接受的。而AOF的出现，将数据丢失风险极大的降低。先不说那么多，实操一把再慢慢聊。

AOF默认情况是没开启的，打开配置文件，为了不让RDB备份影响，这里暂时先将RDB备份禁用掉，如下：

  1. 禁用RDB备份：
image-20201202175142028

  1. 开启AOF备份：根据上一篇文章提到的，先找到APPEND ONLY MODE配置块，将AOF备份开启appendonly yes

    image-20201202175511758

  2. 配置好了，指定配置文件重启redis-server，先来看看效果：

    当一启动redis-server的时候，appendonly.aof文件就已经生成了；来，咱们接着敲点命令，如下↓↓↓

    image-20201202182017360

  3. 尝试打开appendonly.aof文件看看，和dump.rdp文件有什么不同；

    image-20201202182417350

    appendonly.aof只记录写命令，读命令不记录，而且记录方式是以追加的方式，所以速度相对比较快；

同RDB一样，在redis-server重启时，自动加载AOF文件命令依次执行，最终将数据进行恢复；

AOF其他配置项

这就是Redis的强大，针对每一个功能都可以通过配置项进行完成，使用非常方便；

AOF触发重写

当执行的写命令过多时，就会导致AOF文件过度增大，而对于一些重复性的命令存在AOF文件中是没有必要的，如下图所示：

image-20201202233318616

上图中多次对a1这个Key进行多次写入，最终的值为10，可见如果AOF文件中只记录一条最终值的写命令岂不是最好，从而减少AOF文件的大小；这里文件大小肯定达不到自动触发重写的条件，这里就手动触发，然后再看看AOF文件内容，是否进行了优化，如下：

image-20201202234007490

如上图可见，重写之后的AOF文件的确是我们自己想要，是不是觉得Redis更加牛X了；触发重写有以下两种方式：

AOF重写流程
image-20201203000648231

简要说明：

  1. 当触发到重写AOF文件时，主进程fork一个子进程，子进程根据内存中的现有数据进行命令精简化，重写到新的AOF文件中；

  2. 在子进程正在重写AOF文件时，如果有新的写命令，将其存放到重写缓冲区，同时也同步到原来的AOF文件；

  3. 当子进程重写完成之后，通知主进程将重写缓冲区中的新命令写入到新AOF文件中，完成之后，用新的AOF文件将原来的AOF文件替换；

  4. 最后得到优化之后的AOF文件，减少文件大小；

AOF文件修复

对于AOF文件内容的合法性怎么解决呢，有可能由于突然事件，比如宕机，导致AOF文件写入不完整；也有可能有人恶意添加不规范数据，redis会怎么处理呢？这里就模拟手动修改AOF文件，如下：

image-20201203093037933

根据提示，使用redis-check-aof --fix <filename>进行修复，如下：

image-20201203110008592

启动图就不截了，小伙伴们试试去；还有redis也能对rdb文件修复，文中没有体现，但小伙伴记得去尝试一下，用redis-check-rdb这个工具即可，在windows版本中redis没有提供此工具，去linux用高点的版本实操一把。

AOF持久化优缺点

AOF的出现，是解决了RDB丢失最后一次没保存的数据，极大的降低了数据丢失的风险，但其也带来相关问题；

优点

缺点

混合持久化

在redis4.0之后，提供了混合持久化配置开启功能； 混合持久化就是结合RDB和AOF各自优点进行整合的持久化方案，从而解决使用AOF恢复数据较慢的问题；

原理就是在AOF文件的前半段加入RDB快照数据，后面才是增量数据的命令记录；在配置文件中进行配置即可：aof-use-rdb-preamble yes，高版本redis都默认开启这种混合持久化模式；

优点：解决了单纯AOF恢复数据较慢的问题；

缺点：不能兼容低版本redis场景；

选择哪个持久化比较合适？

如果需求对数据完整性要求不是很高，可以接受短时间数据丢失，RDB快照持久化方式是最好不过的选择；

如果对数据完整性要求比较严格，使用AOF日志形式进行持久化比较合适；

如果redis版本在4.0以上，可以使用混合持久化的方式，降低纯AOF文件的恢复数据的时间；

如果仅仅是缓存，缓存数据也不重要，并发也不是很高，可以不用开启持久化；

注： 如果不是使用混合持久化，而是将RDB和AOF同时开启，redis-server恢复数据的时候会优先使用AOF文件进行数据恢复，因为AOF文件相对比较完整；

总结

暂时就到这吧，后续遇到相关问题再来记录分享；这个知识点比较重要，所以小伙伴们一定要自己尝试一下哦；使用真的很简单，进行简单的配置就完事了，如果能知道其简单的原理，遇到问题就没那么苦恼；下次我们来聊redis的主从复制；

一个被程序搞丑的帅小伙，关注"Code综艺圈"，跟我一起学~~~

上一篇 下一篇

猜你喜欢

热点阅读