redis的两种持久化机制及底层原理实现

1、特点

这种方式可以将某一时刻的所有数据都写入硬盘中,当然这也是redis的默认开启持久化方式 ,保存的文件是以**.rdb** 形式结尾的文件因此这种方式也称之为RDB方式 。

• 其实就是类似于linux中的快照，保存当前redis的数据

2、快照生成方式

• 系统默认开启

• 客户端方式：bsave,save指令

• shutdown指令

（1）系统默认开启

• 在redis-conf 中 save设置触发快照持久化的时机

#插入一个linux小知识点，给linxu下的vi显示序号

[root@localhost redis]# vi ~/.vimrc

set hlsearch "高亮度反白

set backspace=2 "可随时用退格键删除

set autoindent "自劢缩排

set ruler "可显示最后一行癿状态

set showmode "左下角那一行癿状态

set nu "可以在每一行癿最前面显示行号啦！

set bg=dark "显示丌同癿底色色调

syntax on "迚行语法检验，颜色显示。

• vi redis.conf

save 900 1 （15分钟内一次写操作） 默认使用bgsave命令

save 300 10 （5分钟10次写操作） 默认使用bgsave命令

save 60 10000 （1分钟内有10000次写操作） 默认使用bgsave命令

（2）客户端快照方式之bgsave

• 客户端方式: bgsave(bg相当于前端的bgcolor:背景颜色)

客户端可以使用BGSAVE命令来创建一个快照,当接收到客户端的BGSAVE命令时,redis会调用fork¹来创建一个子进程,然后子进程负责将快照写入磁盘中,而父进程则继续处理命令请求。

名词解释: fork当一个进程创建子进程的时候,底层的操作系统会创建该进程的一个副本,在类unix系统中创建子进程的操作会进行优化:在刚开始的时候,父子进程共享相同内存,直到父进程或子进程对内存进行了写之后,对被写入的内存的共享才会结束服务

• bgsave指令特点：创建子进程完成快照，初始和主进程使用相同的内存，client发出写操作后会再次分配内存

• bgsave好处 ：1、保证redis服务一直可用 2、完成快照效率高

（3)客户端快照方式之save

客户端还可以使用SAVE命令来创建一个快照,接收到SAVE命令的redis服务器在快照创建完毕之前将不再响应任何其他的命令

• 特点：不会创建子进程 由主进程完成快照

• 好处:创建快照效率高

• 缺陷：redis无法对外提供服务

（4）shutdown指令,关闭redis服务

shutdown指令，关闭redis服务，同时默认触发快照持久化，默认使用的是save指令

（5）修改快照文件的名字和生成位置

名字：dbfilename dump.rdb （253行）

位置：dir./ 表示启动redis服务命令的当前目录

（6）快照持久化方式存在的问题：

持久化需要有触发时机，如果在第一次触发后到第二次触发前发生 发生突发情况 期间的所有数据都会丢失

丢失不定量数据

四、redis持久化机制_AOF 只追加日志文件

============================================================================================

快照持久化：将某个时间点的数据状态存储到一个rdb文件中

AOF持久化：将Client的所写命令存储到一个日志文件中

1、aof持久化默认不开启

在redis的默认配置中AOF持久化机制是没有开启的，需要在配置中开启

2、开启aof持久化

在redis的配置文件中进行配置 redis/redis.conf

appendonly yes 开启aof持久化

默认日志文件的名字：appendonly.aof

#先安装vim，方便查找redis.conf中的文件位置

yum install -y vim

• vim redis.conf 进入672行，将appendonly no改为yes，开启追加日志持久化

2、日志追加频率

• always 每写一个命令追加一次日志文件

• everysec 美妙追加一次日志文件

• no 由操作系统决定

• 修改同步频率

修改appendfsync everysec|always|no 指定

（1）always 【谨慎使用】

• 说明: 每个redis写命令都要同步写入硬盘,严重降低redis速度

• 解释: 如果用户使用了always选项,那么每个redis写命令都会被写入硬盘,从而将发生系统崩溃时出现的数据丢失减到最少;遗憾的是,因为这种同步策略需要对硬盘进行大量的写入操作,所以redis处理命令的速度会受到硬盘性能的限制;

• 注意: 转盘式硬盘在这种频率下200左右个命令/s ; 固态硬盘(SSD) 几百万个命令/s; 1k ssd

• 警告: 使用SSD用户请谨慎使用always选项,这种模式不断写入少量数据的做法有可能会引发严重的写入放大问题,导致将固态硬盘的寿命从原来的几年降低为几个月。

• **特点：保证数据的安全 **

• 决定：效率会降低

（2）everysec 【推荐】

• 说明:每秒执行一次同步显式的将多个写命令同步到磁盘

• 解释： 为了兼顾数据安全和写入性能,用户可以考虑使用everysec选项,让redis每秒一次的频率对AOF文件进行同步;redis每秒同步一次AOF文件时性能和不使用任何持久化特性时的性能相差无几,而通过每秒同步一次AOF文件,redis可以保证,即使系统崩溃,用户最多丢失一秒之内产生的数据。

• 特点：保证突发状况下最多丢失一秒内的数据

（3) no 【不推荐】

• 说明: 由操作系统决定何时同步

• 解释：最后使用no选项,将完全有操作系统决定什么时候同步AOF日志文件,这个选项不会对redis性能带来影响但是系统崩溃时,会丢失不定数量的数据,另外如果用户硬盘处理写入操作不够快的话,当缓冲区被等待写入硬盘数据填满时,redis会处于阻塞状态,并导致redis的处理命令请求的速度变慢。

• 特点：由操作系统决定，不推荐

（4）开启日志之后效果图

添加数据详情

五、AOF重写机制

============================================================================

1、redis数据持久化方式

快照 拍摄数据状态

aof 追加写命令

2、使用AOF出现的问题

写命令一直追加到AOF文件中 导致文件越来越大 问题：存储 加载

解决：进行AOF重写

AOF重写：压缩原有的AOF日志文件

3、触发AOF重写机制

（1）手工Client触发

bgrewriteraof指令

（2）配置Server自动触发

auto-aof-rewrite-percentage 100 后续AOF重写机触发时机 aof文件到达前一次文件的100%触发AOF重写

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

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

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

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

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

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

Kafka进阶篇知识点

Kafka高级篇知识点

44个Kafka知识点（基础+进阶+高级）解析如下

由于篇幅有限，小编已将上面介绍的**《Kafka源码解析与实战》、Kafka面试专题解析、复习学习必备44个Kafka知识点（基础+进阶+高级）都整理成册，全部都是PDF文档**

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
54671a72faed303032d36.jpg" alt=“img” style=“zoom: 33%;” />

Kafka进阶篇知识点

[外链图片转存中…(img-3yL52FQt-1713377929753)]

Kafka高级篇知识点

[外链图片转存中…(img-NsJ9Wjwh-1713377929753)]

44个Kafka知识点（基础+进阶+高级）解析如下

[外链图片转存中…(img-NYXpELnu-1713377929753)]

由于篇幅有限，小编已将上面介绍的**《Kafka源码解析与实战》、Kafka面试专题解析、复习学习必备44个Kafka知识点（基础+进阶+高级）都整理成册，全部都是PDF文档**

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