Redis数据持久化——RDB快照和Aof日志追加

Redis数据持久化

数据持久化:将内存中的数据保存到磁盘中。

作用:让Redis服务重启后可以恢复之前的数据。

一、Redis数据持久化的方式:

 ·RDB(快照):

将内存中Redis缓存的所有数据,都以二进制字符串的方式保存为一个.rdb文件。

特点:占用存储小;当恢复所有数据时,速度快。(恢复某一段数据比较慢,意外宕机还可能丢失几分钟的数据)不建议频繁生成快照。

 ·AOF(日志追加):

将每次增、删、改的操作添加到.aof日志中,默认明文存储(可压缩),占据更大的存储空间,保存数据时,运行资源占用少。追加日志可以实时添加

对比维度

RDB(快照)

AOF(日志)

核心原理

定时生成内存全量数据的二进制快照

实时追加每一条写指令到文本日志

文件格式

二进制文件(.rdb),体积小

文本文件(.aof),体积大(重写前)

数据安全性

安全性低:间隔快照,可能丢失“快照后-宕机前”的数据

安全性高:支持每秒/实时刷盘,最多丢失1秒数据

恢复速度

快:直接解析二进制数据到内存

慢:需重新执行所有写指令

性能影响(运行时

低:仅fork子进程时短暂阻塞,后续无影响

中/高:刷盘频繁(如everysec/always),I/O开销大

性能影响(恢复时

快:适合大规模数据恢复

慢:数据量越大,恢复时间越长

触发方式

自动(save配置)、手动(save/bgsave)

自动(刷盘策略)、手动(bgrewriteaof重写)

适用场景

非核心数据、备份/灾备、可接受数据丢失的场景

核心数据、需高安全性(如金融、交易)的场景

默认开启

是(默认持久化方案)

否(手动配置appendonlyyes)

二、RDB持久化触发机制

触发RDB持久化过程分为手动触发和自动触发

2.1、手动触发:通过 Redis 命令主动生成 RDB:

save:主进程直接执行 RDB,期间会阻塞所有客户端请求(不推荐生产环境,适用于小型数据集);

bgsave:后台保存,主进程 fork 子进程执行 RDB,主进程不阻塞(生产环境首选)。

2.2、自动触发

自动触发持久化,本质是 Redis 通过判断,如果满足设置的触发条件,自动执行一次 bgsave 命令。

通过 redis.conf 配置 “时间 - 修改次数” 规则,满足条件时自动执行 RDB,示例配置:

# 规则格式:save <秒数> <修改次数>

save 900 1       # 900秒内(15分钟)至少1次数据修改,触发RDB

save 300 10      # 300秒内(5分钟)至少10次数据修改,触发RDB

save 60 10000    # 60秒内至少10000次数据修改,触发RDB

当设置多个 save m n 命令时,满足任意一个条件都会触发持久化。

若需禁用自动 RDB,可注释所有 save 配置,或添加 save ""

三、RDB持久化配置

3.1、配置文件

vim /etc/redis/redis.conf

#RDB持久化自动触发条件

save 900 1

save 300 10

save 60 10000

#bgsave持久化失败,是否停止持久化数据到磁盘,yes 表示停止持久化,no 表示忽略错误继续写文件

stop-writes-on-bgsave-error yes

#rdb文件是否压缩

rdbcompression yes

#写入文件和读取文件时是否开启rdb文件检查,检查是否有无损坏,如果在启动是检查发现损坏,则停止启动。

rdbchecksum yes

#rdb持久化后存放的文件名

dbfilename dump.rdb

#rdb持久化后文件的存放路径

dir ./

注意:

文件压缩要是开启的话:Redis 会采用 LZF 算法进行压缩。如果不想消耗 CPU 性能来进行文件压缩的话,可以设置为关闭此功能,这样的缺点是需要更多的磁盘空间来保存文件。

3.2、配置查询/设置

config get xxx

127.0.0.1:6379> config get dir

1) "dir"

2) "/usr/local/redis"

127.0.0.1:6379> config get dbfilename

1) "dbfilename"

2) "dump.rdb"

127.0.0.1:6379> config get stop-writes-on-bgsave-error

1) "stop-writes-on-bgsave-error"

2) "yes"

config set xxx

[root@zuolaoshi /]# cd /usr/local/redis

[root@zuolaoshi redis]# ./bin/redis-cli

127.0.0.1:6379> config set dir "/usr/local/redis/data"

OK

127.0.0.1:6379> config get dir

1) "dir"

2) "/usr/local/redis/data"

注意:

使用命令修改的方式,马上生效,在 Redis 重启之后就会丢失。手动修改 Redis 配置文件,想要立即生效需要重启 Redis 服务器,会一直有效。

3.3、禁用持久化

127.0.0.1:6379> config set save ""

OK

3.4、RDB文件恢复

当 Redis 服务器启动时,Redis 就会自动加载 RDB 文件恢复持久化数据。

验证加载

启动redis时

image20200229014938758.png

四、RDB持久化案例

4.1、手动持久化

127.0.0.1:6379> config set save ""

OK

127.0.0.1:6379> set s helloworld!

OK

127.0.0.1:6379> get s

"helloworld!"

127.0.0.1:6379> save

OK

127.0.0.1:6379> del s

(integer) 1

127.0.0.1:6379> get s

(nil)

127.0.0.1:6379> exit

[root@zuolaoshi redis]# ./bin/redis-cli shutdown

[root@zuolaoshi redis]# ./bin/redis-server /etc/redis/redis.conf

#Redis服务端启动成功提示信息

[root@zuolaoshi redis]# ./bin/redis-cli

127.0.0.1:6379> get s

"helloworld!"

4.2、自动持久化案例

#新建log文件夹

[root@zuolaoshi redis]# mkdir log

#配置日志文件

[root@zuolaoshi redis]# vim redis.conf

#配置:logfile "/usr/local/redis/log/redis.log"

[root@zuolaoshi redis]# ./bin/redis-server /etc/redis/redis.conf

[root@zuolaoshi redis]# ./bin/redis-cli

127.0.0.1:6379> config set save "10 1"

OK

127.0.0.1:6379> config get save

1) "save"

2) "10 1"

127.0.0.1:6379> set a 123

OK

127.0.0.1:6379> set b 456

OK

127.0.0.1:6379> set c 789

OK

127.0.0.1:6379> set d 8910

OK

127.0.0.1:6379> exit

[root@zuolaoshi redis]# cd log

[root@zuolaoshi log]# ls

redis.log

[root@zuolaoshi log]# vim redis.log

image20200229024640021.png

五、AOF持久化

AOF方式在使用Redis存储非临时数据时,一般都需要打开AOF持久化来降低进程终止导致的数据丢失,AOF可以将Redis执行的每一条写命令追加到硬盘文件中,这一过程显然会降低Redis的性能,但是大部分情况下这个影响是可以接受的,另外,使用较快的硬盘能提高AOF的性能。

5.1、AOF工作流

命令写入 (append)、文件同步(sync)、文件重写(rewrite)、重启加载 (load)

image20200303224156711.png

5.2、AOF特点

默认文件名是 appendonly.aof。保存的位置由配置中 dir 来配置目录。

AOF 每次都会保存写命令,数据实时性更高。

AOF 需要使用“重写机制”来优化,每次记录写命令,文件会很大的问题。

AOF 根据不同的“缓冲区同步策略”将我们缓冲区中写入的命令,同步到磁盘。

重写机制

image20200303233558568.png

缓冲区同步策略

设置appendfsync 控制,一共3种:

always:客户端的每一个写操作都保存到aof文件当,这种策略很安全,但是每个写都会有IO操作,所以也很慢。

everysec:每秒写入一次aof文件,因此,最多可能会丢失1s的数据。 推荐使用这种方式。

no: 交由操作系统来处理什么时候写入aof文件。更快,但也是最不安全的选择,不推荐使用。

5.3、持久化恢复

在重启redis服务时,rdb与aof如何执行?

image20200303235441014.png

六、开启AOF持久化

6.1、修改配置

修改配置文件/usr/local/redis/redis.conf

appendonly yes #表示开启AOF持久化,默认是no表示关闭

appendfilename "appendonly.aof" #AOF持久化文件名

appendfsync everysec #缓冲同步策略,默认值

no-appendfsync-on-rewrite no  #是否重写,默认不重写

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若转载,请注明出处:http://www.pswp.cn/bicheng/94794.shtml
繁体地址,请注明出处:http://hk.pswp.cn/bicheng/94794.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

浅聊达梦数据库物理热备的概念及原理

达梦数据库&#xff08;DM Database&#xff09;的物理热备份&#xff0c;核心是在数据库不中断业务&#xff08;联机&#xff09; 的前提下&#xff0c;通过对数据库物理文件&#xff08;如数据文件、控制文件、日志文件等&#xff09;的增量或全量复制&#xff0c;实现数据备…

C++ 中 ::(作用域解析运算符)的用途

C 中 ::&#xff08;作用域解析运算符&#xff09;的应用场景详解 在 C 中&#xff0c;:: 被称为 作用域解析运算符&#xff08;Scope Resolution Operator&#xff09;&#xff0c;用于明确指定某个名字&#xff08;变量、函数、类型等&#xff09;所属的命名空间或类作用域&a…

鸿蒙中CPU活动分析:CPU分析

1 CPU分析的核心概念与重要性 CPU活动分析&#xff08;CPU Profiling&#xff09;是性能优化的核心手段&#xff0c;它通过测量代码执行时间&#xff0c;帮助开发者定位性能瓶颈。应用的响应速度直接影响用户体验&#xff0c;过长的加载时间或卡顿会导致用户流失 1.1 为什么C…

十大经典 Java 算法解析与应用

在 Java 开发的世界里&#xff0c;算法就如同构建大厦的基石&#xff0c;它们支撑着各种复杂应用的高效运行。无论是处理海量数据的排序&#xff0c;还是在庞大结构中精准查找信息&#xff0c;合适的算法都能大幅提升程序的性能。接下来&#xff0c;我们将深入解析十大经典的 J…

从感知机到大模型:神经网络的全景解析与实践指南

从感知机到大模型&#xff1a;神经网络的全景解析与实践指南在当今 AI 时代&#xff0c;我们身边的每一个智能应用 —— 从手机里的人脸识别、语音助手&#xff0c;到聊天机器人 ChatGPT、图像生成工具 MidJourney&#xff0c;再到自动驾驶的环境感知系统 —— 背后都离不开一个…

核心篇(下):Transformer 架构详解(程序员视角・实战版)

在上一篇 NLP 预处理文章中&#xff0c;你已经掌握了 “文本→向量” 的转化流程&#xff0c;解决了 DashScope Tokenizer 的调用问题。但此时你可能会问&#xff1a;“这些向量输入模型后&#xff0c;大模型是如何理解长文本语义的&#xff1f;比如‘小明告诉小红&#xff0c;…

FreeRTOS学习笔记(四):任务执行与切换

第一部分&#xff1a;FreeRTOS 任务是如何执行的&#xff1f; FreeRTOS 是一个抢占式的实时操作系统内核。其任务执行遵循一个核心原则&#xff1a;调度器&#xff08;Scheduler&#xff09;总是选择当前处于“就绪态”&#xff08;Ready&#xff09;的最高优先级任务来运行。 …

区块链技术探索与应用:从密码学奇迹到产业变革引擎

&#x1f31f; Hello&#xff0c;我是蒋星熠Jaxonic&#xff01; &#x1f308; 在浩瀚无垠的技术宇宙中&#xff0c;我是一名执着的星际旅人&#xff0c;用代码绘制探索的轨迹。 &#x1f680; 每一个算法都是我点燃的推进器&#xff0c;每一行代码都是我航行的星图。 &#x…

如何监控和调优JVM的内存使用情况?

监控和调优 JVM 内存使用是保障 Java 应用稳定性和性能的核心手段&#xff0c;需要结合监控工具、关键指标分析和针对性调优策略。以下是具体的实施方法&#xff1a;一、JVM 内存监控&#xff1a;工具与核心指标监控的目标是掌握内存使用趋势、GC 行为、线程状态等&#xff0c;…

把用户输进来的明文密码做一层 MD5 哈希

这一行干的就是&#xff1a;把用户输进来的明文密码先做一层 MD5 哈希&#xff0c;再把得到的 32 位十六进制字符串存到变量 password 里。 逐段拆开&#xff1a;password.getBytes() 把字符串转成字节数组&#xff0c;MD5 算法只能对字节/字节数组做运算。DigestUtils.md5Dige…

jeecg-boot3.7.0对接钉钉登录(OAuth2.0)

当前的jeecg-boot 是3.7.0前端问题&#xff1a;1.前端的路由vue-router的版本需要固定死。要不然会报page_not_found router the same.这种奇奇怪怪的问题。 就是把package.json的“^”&#xff0c;这个符号&#xff0c;删掉。&#xff08;或者全局搜索&#xff0c;这个page no…

【C#】获取不重复的编码(递增,非GUID)

获取不重复的编码&#xff1a;从原始实现到高效优化本文针对软件开发中“为新对象分配唯一编码”的常见需求&#xff0c;以C#通信设备管理场景为例&#xff0c;从原始代码分析入手&#xff0c;逐步讲解基于LINQ和哈希集合的优化方案&#xff0c;帮助开发者理解不同场景下的最佳…

腾讯云人脸库技术架构深度解析

腾讯云人脸库技术架构深度解析人脸库是现代人脸识别系统的核心组件&#xff0c;负责海量人脸特征的高效存储、检索和管理。腾讯云在人脸库设计上采用了多项创新技术&#xff0c;本文将深入探讨其技术实现细节。一、人脸库核心架构腾讯云人脸库采用分层架构设计&#xff1a;应用…

Transformer图解指南:Attention机制动画演示

点击 “AladdinEdu&#xff0c;同学们用得起的【H卡】算力平台”&#xff0c;H卡级别算力&#xff0c;按量计费&#xff0c;灵活弹性&#xff0c;顶级配置&#xff0c;学生专属优惠。 Self-Attention矩阵运算 位置编码可视化 读者收获&#xff1a;理解大模型基石架构 Attenti…

工业网络安全:保护制造系统和数据

近年来&#xff0c;制造业数字化转型加速推进。自动化生产线、智能工厂和工业物联网设备已深度融入日常运营。这些进步在提升效率的同时&#xff0c;也暴露出新的安全漏洞。因此&#xff0c;工业网络安全已成为全球制造商的首要任务之一。与主要保护办公系统和客户数据库的传统…

【RAGFlow代码详解-9】文档解析和 OCR

系统概述 文档解析和 OCR 系统提供多格式文档支持&#xff0c;并具有基于视觉的分析功能。它由几个关键组件组成&#xff1a; DeepDoc 视觉系统 &#xff1a;用于布局分析、表格检测和 OCR 的高级计算机视觉模型多格式解析器 &#xff1a;支持 PDF、DOCX、Excel、Markdown、HTM…

元宇宙与医疗健康:重构诊疗体验与健康管理模式

1 元宇宙重塑医疗诊疗核心流程1.1 远程诊疗&#xff1a;从 “平面沟通” 到 “沉浸式问诊”元宇宙打破远程诊疗的空间限制&#xff0c;将传统 “视频通话式问诊” 升级为 “沉浸式多维度交互”。在基础问诊环节&#xff0c;医生的数字分身可通过 AR 技术 “进入” 患者家中&…

C6.1:发射极偏置放大器

基极偏置放大器的Q点不稳定&#xff0c;但是学习后了解了放大器的基本运行逻辑&#xff0c;发射极偏置放大器则是适合大规模应用&#xff0c;VDB和TSEB都具有稳定的Q点。讲发射极偏置&#xff0c;首先要讲旁路电容&#xff0c;前文的耦合电容和旁路电容类似&#xff0c;都是直流…

lanczos算法中的基向量V的存储流程

我的问题是&#xff1a;这里提到的&#xff0c;为什么会增加V的列向量&#xff1f;V是怎么储存的呢&#xff1f; 这个问题触及了Lanczos算法实现的核心细节。 &#x1f9e0; 为什么会增加V的列向量&#xff1f; 因为Lanczos算法是一个迭代过程&#xff0c;它从一个初始向量开始…

Linux操作系统——TCP服务端并发模型

TCP&#xff1a;建立连接&#xff0c;一对一要实现多任务并发&#xff0c;就引出了并发模型一、多进程与多线程1.在相同资源情况下&#xff0c;进程资源开销大&#xff0c;但其安全性高2.线程相对于进程资源开销小&#xff0c;且并发量比进程大①多进程并发基础代码#include &l…