Redis持久化AOF与RDB全面解析(大厂面试必问,看完之后offer直接到手,你学废了吗?),分布式架构演进+相关笔记参考

  • 数据的备份更加完整,丢失数据的概率更低,适合对数据完整性要求高的场景

  • 日志文件可读,AOF可操作性更强,可通过操作日志文件进行修复

缺点:

  • AOF日志记录在长期运行中逐渐庞大,恢复起来非常耗时,需要定期对AOF日志进行瘦身处理(后续详述)

  • 恢复备份速度比较慢

  • 同步写操作频繁会带来性能压力

官网地址

http://www.redis.io

2、RDB


2.1 简介

RDB持久化方案进行备份时,Redis会单独fork一个子进程来进行持久化,会将数据写入一个临时文件中,持久化完成后替换旧的RDB文件。在整个持久化过程中,主进程(为客户端提供服务的进程)不参与IO操作,这样能确保Redis服务的高性能,RDB持久化机制适合对数据完整性要求不高但追求高效恢复的使用场景。

下面展示RDB持久化流程:

Redis-RDB流程.png

2.2 Fork

上面说到了RDB持久化过程中,主进程会fork一个子进程来负责RDB的备份,这里简单介绍一下fork

  • Linux操作系统中的程序,fork会产生一个和父进程完全相同的子进程。子进程与父进程所有的数据均一致,但是子进程是一个全新的进程,与原进程是父子进程关系

  • 出于效率考虑,Linux操作系统中使用COW(Copy On Write)写时复制机制,fork子进程一般情况下与父进程共同使用一段物理内存,只有在进程空间中的内存发生修改时,内存空间才会复制一份出来。

在Redis中,RDB持久化就是充分的利用了这项技术,Redis在持久化时调用glibc函数fork一个子进程,全权负责持久化工作,这样父进程仍然能继续给客户端提供服务。fork的子进程初始时与父进程(Redis的主进程)共享同一块内存;当持久化过程中,客户端的请求对内存中的数据进行修改,此时就会通过COW机制对数据段页面进行分离,也就是复制一块内存出来给主进程去修改。

cow示意图 (1).png

RDB触发的规则分为两大类,分别是手动触发和自动触发:

自动触发:

  1. 配置触发规则

  2. shutdown触发

  3. flushall触发

手动触发:

  1. save

  2. bgsave

2.3 自动触发

以下介绍Redis的RDB持久化机制中的自动触发机制中的配置触发规则来触发RDB,涉及到RDB规则的配置、文件存储路径配置、文件名配置、文件压缩配置、文件完整性校验配置。

2.3.1 配置规则触发

  • 在Redis安装目录下的redis.conf配置文件中搜索 /snapshot即可快速定位,配置文件默认注释了下面三行数据,通过配置规则来触发RDB的持久化,需要开启或者根据自己的需求按照规则来配置。

image.png

下面对配置规则进行解释,实际使用过程中可以根据需求进行合理的配置

save 3600 1 -> 3600秒内有1个key被修改,触发RDB

save 300 100 -> 300 秒内有100个key被修改,触发RDB

save 60 10000 -> 60 秒内有10000个key被修改,触发RDB

  • 配置RDB文件的存储路径

image.png

我们可以在Redis的安装目录下看到dump.rdb文件,如果没看到,连接到客户端执行一次shutdown,这个是后面shutdown自动触发规则,后续会讲述

image.png

  • 配置RDB文件的名称

image.png

  • 配置RDB文件压缩

Redis默认会使用LZF算法对Redis的RDB文件进行压缩,这会消耗一定的CPU计算资源,但是会带来空间上的节省

image.png

  • 配置RDB文件完整性校验

Redis 默认使用CRC64的算法,对RDB文件完整性进行校验,以此来保证RDB文件的完整

image.png

2.3.2 shutdown触发

shutdown触发Redis的RDB持久化机制非常简单,我们在客户端执行shutdown即可。

image.png

2.3.3 flushall触发

首先这里一定要特别注意,flushall是删库跑路,它是清空dump.rdb文件,千万千万不要看了博主的文章,跑到公司备份的时候顺手来个flushall,然后到时候来问候我……,这个flushall是为了清空Redis数据的同时清空dump.rdb文件,要不然重启Redis的时候,数据又会恢复到上一次备份的时候的数据,与flushall的执行指令含义就冲突了。

为了证明这个文件不会保留数据,我特地特地的写个脚本测试一下:

编写一个批量插入的脚本文件

vi batchKeyInsert.sh

#!/bin/bash

for((i=0;i<100000;i++))

do

echo -en “Hello Redis.” | redis-cli -h 192.168.211.108 -p 6379 -c -x set name$i >>redis.log

done

文件赋权

chmod +x batchKeyInsert.sh

image.png

./batchKeyInsert.sh

image.png

此时查看dump.rdb

image.png

执行flushall,后再次查看,rbd文件被清空

image.png

2.2 手动触发

手动触发RDB持久化的方式可以使用save命令和bgsave命令,这两个命令的区别如下。

save:执行save指令,阻塞Redis的其他操作,会导致Redis无法响应客户端请求,不建议使用。

bgsave:执行bgsave指令,Redis后台异步进行快照的保存操作,此时Redis仍然能响应客户端的请求。

2.3 RDB持久化文件的备份

在实际的生产环境中,我们一般不会使用主节点Master来进行持久化备份,我们会通过在Redis的多个从服务器上进行RDB持久化备份,这样是为了对Redis数据的多次备份,防止出现网络分区或者部分节点宕机甚至是硬件损坏的情况发生。

作为运维或者架构师,李子捌觉得应该要定时定期的通过脚本对Redis持久化文件进行转移备份,这样双重保险,更加可靠,万一遇到突发情况,也是多一手解决方案。

3、AOF


3.1 简介

Redis配置文件中开启,AOF持久化方案进行备份时,客户端所有请求的写命令都会被追加到AOF缓冲区中,缓冲区中的数据会根据Redis配置文件中配置的同步策略来同步到磁盘上的AOF文件中,同时当AOF的文件达到重写策略配置的阈值时,Redis会对AOF日志文件进行重写,给AOF日志文件瘦身。Redis服务重启的时候,通过加载AOF日志文件来恢复数据。

Redis-AOF持久化流程 (2).png

3.2 AOF配置

AOF默认不开启,默认为appendonly no,开启则需要修改为appendonly yes

image.png

AOF配置文件的名称默认为appendonly.aof

image.png

配置文件的地址可以通过在redis客户端执行config get dir获取,其保存路径与RDB一致

image.png

3.2.2 同步频率配置

AOF日志是以文件的形式存在的,当程序对AOF日志文件进行写操作时,实际上将内容写到了内核为文件描述符分配的一个内存缓冲区中,随后内核会异步的将缓冲区中的数据刷新到磁盘中。如果缓冲区中的数据没来得及刷回磁盘时,服务器宕机了,这些数据就会丢失。

因此Redis通过调用Linux操作系统的glibc提供的fsync(int fid)来将指定文件的内容强制从内核缓冲区刷回磁盘,以此来保证缓冲区中的数据不会丢失。不过这是一个IO操作,相比Redis的性能来说它是非常慢的,所以不能频繁的执行。

Redis配置文件中有三种刷新缓冲区的配置:

appendfsync always

每次Redis写操作,都写入AOF日志,这种配置理论上Linux操作系统扛不住,因为Redis的并发远远超过了Linux操作系统提供的最大刷新频率,就算Redis写操作比较少的情况,这种配置也是非常耗性能的,因为涉及到IO操作,所以这个配置基本上不会用

appendfsync everysec

每秒刷新一次缓冲区中的数据到AOF文件,这个Redis配置文件中默认的策略,兼容了性能和数据完整性的折中方案,这种配置,理论上丢失的数据在一秒钟左右

appendfsync no

Redis进程不会主动的去刷新缓冲区中的数据到AOF文件中,而是直接交给操作系统去判断,这种操作也是不推荐的,丢失数据的可能性非常大。

image.png

注意要刷新缓冲区的数据到磁盘需要将如下配置,配置为no,不是yes

no-appendfsync-on-rewrite no

3.3 AOF修复功能

AOF持久化机制正常恢复与RDB持久化机制的恢复是一样的,都只需要将备份文件放置到Redis的工作目录下,Redis启动时就会自动的加载。AOF持久化机制提供了AOF文件异常时恢复的功能,这个功能在AOF文件损坏的场景中经常被使用到。

测试,清空Redis服务中的数据

image.png

写入数据

image.png

AOF日志文件每秒会被刷新一次数据,此时数据已经写入了appendonly.aof文件

image.png

打开文件我们可以非常清除的阅读AOF的文件内容,看到Redis的指令序列

image.png

此时人为的进行数据破坏

image.png

再次启动发现无法启动(我配置的别名启动)

image.png

执行redis-check-aof --fix …/appendonly.aof 对AOF日志文件进行修复

image.png

修复过程中会有部分数据丢失

image.png

连接客户端查看数据

image.png

3.4 AOF重写

自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。

深知大多数初中级Android工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则近万的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!

因此收集整理了一份《2024年Android移动开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。

img

img

img

img

既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Android开发知识点,真正体系化!

由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!

如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:Android)

最后

由于题目很多整理答案的工作量太大,所以仅限于提供知识点,详细的很多问题和参考答案我都整理成了 PDF文件

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!

这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!**

如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:Android)

最后

由于题目很多整理答案的工作量太大,所以仅限于提供知识点,详细的很多问题和参考答案我都整理成了 PDF文件

[外链图片转存中…(img-HIxqSese-1712795924173)]

[外链图片转存中…(img-TXPBwTkw-1712795924173)]

[外链图片转存中…(img-C2019OKU-1712795924173)]

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!

  • 22
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值