大数据最全Redis持久化数据之RDB和AOF_redisrdb数据持久化的特点，2024大数据开发高频精选面试题讲解

2401_84166306

已于 2024-05-07 07:08:21 修改

阅读量905

点赞数 7

分类专栏：程序员文章标签：大数据 redis 数据库

于 2024-05-07 07:08:20 首次发布

本文链接：https://blog.csdn.net/2401_84166306/article/details/138517466

版权

程序员专栏收录该内容

184 篇文章 0 订阅

订阅专栏

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

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

配置

dump.rdb : 使用RDB生成的默认文件名称

在这里插入图片描述

dir ./ : rdb文件的保存路径，默认为Redis启动时命令行所在的目录下

在这里插入图片描述

stop-writes-on-bgsave-error：当Redis无法写入磁盘的话，直接关掉Redis的写操作。

在这里插入图片描述

rdbcompression：对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能。

在这里插入图片描述

rdbchecksum ：在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能

在这里插入图片描述

save：秒钟写操作次数
RDB是整个内存的压缩过的Snapshot，RDB的数据结构，可以配置复合的快照触发条件，
默认是1分钟内改了1万次，或5分钟内改了10次，或15分钟内改了1次。

在这里插入图片描述

此处为save配置的一些规则说明（此规则可以进行修改）：

3600秒后一个key发生改变进行数据持久化操作
…

在这里插入图片描述

优势和劣势

① 优势：

适合大规模的数据恢复
对数据完整性和一致性要求不高更适合使用
节省磁盘空间
恢复速度快

② 劣势：

Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑。
虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

二、AOF（Append Of File）

概述

以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

AOF持久化过程

客户端的请求写命令会被append追加到AOF缓冲区内；
AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；
AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

在这里插入图片描述

AOF 配置

AOF 默认是不开启的，需要将其设置为 yes

在这里插入图片描述

生成默认的文件名

在这里插入图片描述

AOF 文件路径默认和dump.rdb路径一致

在这里插入图片描述

我们可以看到AOF文件中是没有数据的，连接上redis客户端，发现也是没有数据的。

在这里插入图片描述
但是rdm中之前是有数据的。

那么AOF和RDB同时开启，redis听谁的？

其实，AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）。

AOF同步频率设置:
appendfsync always ：始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好
appendfsync everysec ：每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
appendfsync no ：redis不主动进行同步，把同步时机交给操作系统。

在这里插入图片描述

Rewrite 压缩

定义？

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。

重写原理：

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，redis4.0版本后的重写，是指上就是把rdb 的快照，以二级制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。
no-appendfsync-on-rewrite=yes ,不写入aof文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）。
no-appendfsync-on-rewrite=no, 还是会把数据往磁盘里刷，但是遇到重写操作，可能会发生阻塞。（数据安全，但是性能降低）。

触发机制？

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。
auto-aof-rewrite-percentage：设置重写的基准值，文件达到100%时开始重写（文件是原来重写后文件的2倍时触发）
auto-aof-rewrite-min-size：设置重写的基准值，最小文件64MB。达到这个值开始重写。

重写流程：

bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。
主进程fork出子进程执行重写操作，保证主进程不会阻塞。
子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。
（1）子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。
（2）主进程把aof_rewrite_buf中的数据写入到新的AOF文件。
使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。

在这里插入图片描述