Redis持久化AOF与RDB全面解析（大厂面试必问，看完之后offer直接到手，你学废了吗？）(1)

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

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

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

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

如果你需要这些资料，可以添加V获取：vip204888 （备注Android）

正文

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

自动触发：

1. 配置触发规则

2. shutdown触发

3. flushall触发

手动触发：

1. save

2. bgsave

2.3 自动触发

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

​

2.3.1 配置规则触发

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

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

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

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

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

• 配置RDB文件的存储路径

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

• 配置RDB文件的名称

• 配置RDB文件压缩

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

• 配置RDB文件完整性校验

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

2.3.2 shutdown触发

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

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

./batchKeyInsert.sh

此时查看dump.rdb

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

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日志文件来恢复数据。

3.2 AOF配置

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

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

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

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文件中，而是直接交给操作系统去判断，这种操作也是不推荐的，丢失数据的可能性非常大。

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

no-appendfsync-on-rewrite no

3.3 AOF修复功能

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

​测试，清空Redis服务中的数据

写入数据

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

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

此时人为的进行数据破坏

再次启动发现无法启动（我配置的别名启动）

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

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

连接客户端查看数据

3.4 AOF重写

前面提到AOF的缺点时，说过AOF属于日志追加的形式来存储Redis的写指令，这会导致大量冗余的指令存储，从而使得AOF日志文件非常庞大，比如同一个key被写了10000次，最后却被删除了，这种情况不仅占内存，也会导致恢复的时候非常缓慢，因此Redis提供重写机制来解决这个问题。Redis的AOF持久化机制执行重写后，保存的只是恢复数据的最小指令集，我们如果想手动触发可以使用如下指令：

bgrewriteaof

Redis4.0后的重写使用的是RDB快照和AOF指令拼接的方式，在AOF文件的头部是RDB快照的二进制形式的数据，尾部是快照产生后发生的写入操作的指令。

由于重写AOF文件时，会对Redis的性能带来一定的影响，因此也不能随便的进行自动重写，Redis提供两个配置用于自动进行AOF重写的指标，只有这两个指标同时满足的时候才会发生重写：

auto-aof-rewrite-percentage 100：指的是当文件的内存达到原先内存的两倍

auto-aof-rewrite-min-size 64mb：指的是文件重写的最小内存大小

AOF重写流程如下：

总结

现在新技术层出不穷，如果每次出新的技术，我们都深入的研究的话，很容易分散精力。新的技术可能很久之后我们才会在工作中用得上，当学的新技术无法学以致用，很容易被我们遗忘，到最后真的需要使用的时候，又要从头来过（虽然上手会更快）。

我觉得身为技术人，针对新技术应该是持拥抱态度的，入了这一行你就应该知道这是一个活到老学到老的行业，所以面对新技术，不要抵触，拥抱变化就好了。

Flutter 明显是一种全新的技术，而对于这个新技术在发布之初，花一个月的时间学习它，成本确实过高。但是周末花一天时间体验一下它的开发流程，了解一下它的优缺点、能干什么或者不能干什么。这个时间，并不是我们不能接受的。

如果有时间，其实通读一遍 Flutter 的文档，是最全面的一次对 Flutter 的了解过程。但是如果我们只有 8 小时的时间，我希望能关注一些最值得关注的点。

（跨平台开发(Flutter)、java基础与原理，自定义view、NDK、架构设计、性能优化、完整商业项目开发等）

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注Android）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

如果有时间，其实通读一遍 Flutter 的文档，是最全面的一次对 Flutter 的了解过程。但是如果我们只有 8 小时的时间，我希望能关注一些最值得关注的点。

（跨平台开发(Flutter)、java基础与原理，自定义view、NDK、架构设计、性能优化、完整商业项目开发等）

[外链图片转存中…(img-5HLo2H4M-1713570028209)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注Android）
[外链图片转存中…(img-0uepGodY-1713570028210)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！