全解:Redis RDB持久化和AOF持久化

🧑 博主简介:CSDN博客专家历代文学网(PC端可以访问:https://literature.sinhy.com/#/literature?__c=1000,移动端可微信小程序搜索“历代文学”)总架构师,15年工作经验,精通Java编程高并发设计Springboot和微服务,熟悉LinuxESXI虚拟化以及云原生Docker和K8s,热衷于探索科技的边界,并将理论知识转化为实际应用。保持对新技术的好奇心,乐于分享所学,希望通过我的实践经历和见解,启发他人的创新思维。在这里,我希望能与志同道合的朋友交流探讨,共同进步,一起在技术的世界里不断学习成长。
技术合作请加本人wx(注明来自csdn):foreast_sea

在这里插入图片描述


在这里插入图片描述

全解:Redis RDB持久化和AOF持久化

在当今数据驱动的时代,数据的安全性与可靠性是任何系统都不容忽视的关键要素。Redis 作为一款广泛应用的高性能内存数据库,其数据持久化机制尤为重要。

持久化,简单来说,就是将内存中的数据以某种形式保存到磁盘等持久存储介质上的过程。Redis 之所以需要持久化,是因为内存数据具有易失性。一旦服务器遭遇意外断电、系统故障或其他突发情况,若没有持久化机制,内存中的数据将瞬间丢失,这对于依赖 Redis 存储关键信息的应用来说可能是灾难性的打击。

Redis 实现持久化主要通过 RDB 和 AOF 两种方式。RDB 持久化采用定期快照的策略,在特定的时间点将 Redis 数据集的全量数据以二进制的形式保存到磁盘。这种方式在数据恢复时速度较快,适合用于大规模数据的备份与恢复场景,且生成的 RDB 文件相对紧凑,便于传输与存储。

而 AOF 持久化则是基于日志记录的方式,它会将 Redis 执行的写命令以追加的形式记录到 AOF 文件中。这样在恢复数据时,只需重新执行这些写命令即可重建数据集。AOF 持久化的优势在于它能够提供更精细的数据恢复粒度,数据丢失风险相对较低,并且可以通过配置不同的刷盘策略来平衡数据安全性与性能。

本文将深入剖析 Redis 的 RDB 持久化和 AOF 持久化,详细探讨它们各自的工作原理、实现细节以及优缺点,帮助读者全面理解这两种持久化机制,从而在实际使用 Redis 时能够根据具体的应用场景与需求,合理地选择和配置持久化策略,确保数据的安全性与系统的稳定性。

文章目录

  • 全解:Redis RDB持久化和AOF持久化
    • 什么是持久化?
    • Redis为什么要持久化?
    • Redis如何实现持久化?
    • RDB持久化
    • AOF持久化
    • RDB和AOF的优缺点

什么是持久化?

持久化(Persistence),即把数据(如内存中的对象)保存到可永久保存的存储设备中(如磁盘)。持久化的主要应用是将内存中的对象存储在数据库中,或者存储在磁盘文件中、XML数据文件中等等。

在这里插入图片描述

还可以从如下两个层面简单的理解持久化 :

  • 应用层:如果关闭(shutdown)你的应用然后重新启动则先前的数据依然存在。
  • 系统层:如果关闭(shutdown)你的系统(电脑)然后重新启动则先前的数据依然存在。

Redis为什么要持久化?

Redis是内存数据库,为了保证效率所有的操作都是在内存中完成。数据都是缓存在内存中,当你重启系统或者关闭系统,之前缓存在内存中的数据都会丢失再也不能找回。因此为了避免这种情况,Redis需要实现持久化将内存中的数据存储起来。

Redis如何实现持久化?

Redis官方提供了不同级别的持久化方式:

  • RDB持久化:能够在指定的时间间隔能对你的数据进行快照存储。
  • AOF持久化:记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾。Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大。
  • 不使用持久化:如果你只希望你的数据在服务器运行的时候存在,你也可以选择不使用任何持久化方式。
  • 同时开启RDB和AOF:你也可以同时开启两种持久化方式,在这种情况下当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

这么多持久化方式我们应该怎么选?在选择之前我们需要搞清楚每种持久化方式的区别以及各自的优劣势。

RDB持久化

RDB(Redis Database)持久化是把当前内存数据生成快照保存到硬盘的过程,触发RDB持久化过程分为手动触发自动触发

(1)手动触发

手动触发对应save命令,会阻塞当前Redis服务器,直到RDB过程完成为止,对于内存比较大的实例会造成长时间阻塞,线上环境不建议使用。

(2)自动触发

自动触发对应bgsave命令,Redis进程执行fork操作创建子进程,RDB持久化过程由子进程负责,完成后自动结束。阻塞只发生在fork阶段,一般时间很短。

在redis.conf配置文件中可以配置:

save <seconds> <changes>

表示xx秒内数据修改xx次时自动触发bgsave。
如果想关闭自动触发,可以在save命令后面加一个空串,即:

save ""

还有其他常见可以触发bgsave,如:

  • 如果从节点执行全量复制操作,主节点自动执行bgsave生成RDB文件并发送给从节点。
  • 默认情况下执行shutdown命令时,如果没有开启AOF持久化功能则 自动执行bgsave。

bgsave工作机制

在这里插入图片描述

(1)执行bgsave命令,Redis父进程判断当前是否存在正在执行的子进 程,如RDB/AOF子进程,如果存在,bgsave命令直接返回。

(2)父进程执行fork操作创建子进程,fork操作过程中父进程会阻塞,通 过info stats命令查看latest_fork_usec选项,可以获取最近一个fork操作的耗时,单位为微秒

(3)父进程fork完成后,bgsave命令返回“Background saving started”信息并不再阻塞父进程,可以继续响应其他命令。

(4)子进程创建RDB文件,根据父进程内存生成临时快照文件,完成后对原有文件进行原子替换。执行lastsave命令可以获取最后一次生成RDB的 时间,对应info统计的rdb_last_save_time选项。

(5)进程发送信号给父进程表示完成,父进程更新统计信息,具体见 info Persistence下的rdb_*相关选项。

AOF持久化

AOF(append only file)持久化:以独立日志的方式记录每次写命令, 重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性,目前已经是Redis持久化的主流方式。

AOF持久化工作机制

开启AOF功能需要配置:appendonly yes,默认不开启。

AOF文件名 通过appendfilename配置设置,默认文件名是appendonly.aof。保存路径同 RDB持久化方式一致,通过dir配置指定。

AOF的工作流程操作:命令写入 (append)、文件同步(sync)、文件重写(rewrite)、重启加载 (load)。

在这里插入图片描述

(1)所有的写入命令会追加到aof_buf(缓冲区)中。

(2)AOF缓冲区根据对应的策略向硬盘做同步操作。

AOF为什么把命令追加到aof_buf中?Redis使用单线程响应命令,如果每次写AOF文件命令都直接追加到硬盘,那么性能完全取决于当前硬盘负载。先写入缓冲区aof_buf中,还有另一个好处,Redis可以提供多种缓冲区同步硬盘的策略,在性能和安全性方面做出平衡。

(3)随着AOF文件越来越大,需要定期对AOF文件进行重写,达到压缩的目的。

(4)当Redis服务器重启时,可以加载AOF文件进行数据恢复。

AOF重写(rewrite)机制

重写的目的:

  • 减小AOF文件占用空间;
  • 更小的AOF 文件可以更快地被Redis加载恢复。

AOF重写可以分为手动触发和自动触发:

  • 手动触发:直接调用bgrewriteaof命令。
  • 自动触发:根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。

auto-aof-rewrite-min-size:表示运行AOF重写时文件最小体积,默认 为64MB。

auto-aof-rewrite-percentage:代表当前AOF文件空间 (aof_current_size)和上一次重写后AOF文件空间(aof_base_size)的比值。

自动触发时机

当aof_current_size>auto-aof-rewrite-minsize 并且(aof_current_size-aof_base_size)/aof_base_size>=auto-aof-rewritepercentage。

其中aof_current_size和aof_base_size可以在info Persistence统计信息中查看。

在这里插入图片描述

AOF文件重写后为什么会变小?

(1)旧的AOF文件含有无效的命令,如:del key1, hdel key2等。重写只保留最终数据的写入命令。

(2)多条命令可以合并,如lpush list a,lpush list b,lpush list c可以直接转化为lpush list a b c。

AOF文件数据恢复

在这里插入图片描述

数据恢复流程说明:

(1)AOF持久化开启且存在AOF文件时,优先加载AOF文件。

(2)AOF关闭或者AOF文件不存在时,加载RDB文件。

(3)加载AOF/RDB文件成功后,Redis启动成功。

(4)AOF/RDB文件存在错误时,Redis启动失败并打印错误信息。

RDB和AOF的优缺点

RDB优点

  • RDB 是一个非常紧凑的文件,它保存了某个时间点的数据集,非常适用于数据集的备份,比如你可以在每个小时报保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题你也可以根据需求恢复到不同版本的数据集。
  • RDB 是一个紧凑的单一文件,很方便传送到另一个远端数据中心,非常适用于灾难恢复。
  • RDB 在保存 RDB 文件时父进程唯一需要做的就是 fork 出一个子进程,接下来的工作全部由子进程来做,父进程不需要再做其他 IO 操作,所以 RDB 持久化方式可以最大化 Redis 的性能。
  • 与AOF相比,在恢复大的数据集的时候,RDB 方式会更快一些。

AOF优点

  • 你可以使用不同的 fsync 策略:无 fsync、每秒 fsync 、每次写的时候 fsync .使用默认的每秒 fsync 策略, Redis 的性能依然很好( fsync 是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障,你最多丢失1秒的数据。

  • AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满,写的过程中宕机等等)未执行完整的写入命令,你也也可使用redis-check-aof工具修复这些问题。

  • Redis 可以在 AOF 文件体积变得过大时,自动地在后台对 AOF 进行重写: 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的,因为 Redis 在创建新 AOF 文件的过程中,会继续将命令追加到现有的 AOF 文件里面,即使重写过程中发生停机,现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕,Redis 就会从旧 AOF 文件切换到新 AOF 文件,并开始对新 AOF 文件进行追加操作。

  • AOF 文件有序地保存了对数据库执行的所有写入操作, 这些写入操作以 Redis 协议的格式保存, 因此 AOF 文件的内容非常容易被人读懂, 对文件进行分析(parse)也很轻松。 导出(exportAOF 文件也非常简单: 举个例子, 如果你不小心执行了 FLUSHALL 命令, 但只要 AOF 文件未被重写, 那么只要停止服务器, 移除 AOF 文件末尾的 FLUSHALL 命令, 并重启 Redis , 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

RDB缺点

  • Redis 要完整的保存整个数据集是一个比较繁重的工作,你通常会每隔5分钟或者更久做一次完整的保存,万一在 Redis 意外宕机,你可能会丢失几分钟的数据。
  • RDB 需要经常 fork 子进程来保存数据集到硬盘上,当数据集比较大的时候, fork 的过程是非常耗时的,可能会导致 Redis 在一些毫秒级内不能响应客户端的请求。

AOF缺点

  • 对于相同的数据集来说,AOF 文件的体积通常要大于 RDB 文件的体积。
  • 数据恢复(load)时AOF比RDB慢,通常RDB 可以提供更有保证的最大延迟时间。

RDB和AOF简单对比总结

RDB优点:

  • RDB 是紧凑的二进制文件,比较适合备份,全量复制等场景
  • RDB 恢复数据远快于 AOF

RDB缺点:

  • RDB 无法实现实时或者秒级持久化;
  • 新老版本无法兼容 RDB 格式。

AOF优点:

  • 可以更好地保护数据不丢失;
  • appen-only 模式写入性能比较高;
  • 适合做灾难性的误删除紧急恢复。

AOF缺点:

  • 对于同一份文件,AOF 文件要比 RDB 快照大;
  • AOF 开启后,会对写的 QPS 有所影响,相对于 RDB 来说 写 QPS 要下降;
  • 数据库恢复比较慢, 不合适做冷备。

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

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

相关文章

QILSTE H6-C210LB/5M高亮蓝光LED灯珠 发光二极管LED

在电子照明领域&#xff0c;H6-C210LB/5M&#xff0c;这款高亮蓝光LED&#xff0c;以其精确的参数和卓越的性能&#xff0c;脱颖而出。本文将通过增加文本的复杂性和长短句的交替使用&#xff0c;深入探讨这款LED的技术参数&#xff0c;以增强文章的困惑性和突发性。 **H6-C21…

使用 ASP.NET Core HttpLoggingMiddleware 记录 http 请求/响应

我们发布了一个应用程序&#xff0c;该应用程序运行在一个相当隐蔽的 WAF 后面。他们向我们保证&#xff0c;他们的产品不会以任何方式干扰我们的应用程序。这是错误的。他们删除了我们几乎所有的“自定义”标头。为了“证明”这一点&#xff0c;我构建了一个中间件&#xff0c…

回调机制详解

一、什么是回调&#xff1a; 回调是一种双向的调用模式&#xff0c;程序模块之间通过这样的接口调用完成通信联系&#xff0c;回调的核心就是回调方将本身即this传递给调用方&#xff0c;这样调用方就可以在调用完毕之后再告诉回调方它想要知道的信息。 回调函数用于层间协作&…

CUDA 计时功能,记录GPU程序/函数耗时,cudaEventCreate,cudaEventRecord,cudaEventElapsedTime

为了测试GPU函数的耗时&#xff0c;可以使用 CUDA 提供的计时功能&#xff1a;cudaEventCreate, cudaEventRecord, 和 cudaEventElapsedTime。这些函数可以帮助你测量某个 CUDA 操作&#xff08;如设置设备&#xff09;所花费的时间。 一、记录耗时案例 以下是一个示例程序&a…

ISO45001职业健康安全管理体系认证流程

前期准备 领导决策&#xff1a;企业高层领导需认识到实施 ISO 45001 体系的重要性和必要性&#xff0c;做出认证决策&#xff0c;并承诺提供必要的资源支持。成立工作小组&#xff1a;由企业各相关部门人员组成工作小组&#xff0c;明确各成员的职责和分工&#xff0c;确保工作…

异步操作,promise、axios

一、异步操作&#xff08;异步编程&#xff09;、同步操作 异步操作是指在编程中&#xff0c;某个任务的执行不会立即完成&#xff0c;同时不会阻塞后续代码的执行。在异步操作中&#xff0c;程序可以继续运行&#xff0c;并在异步任务完成时得到通知并处理结果。这与同步操作…

Ansible的yum和saltstack的哪个功能相似

Ansible的yum和saltstack的哪个功能相似 在 Ansible 和 SaltStack 中&#xff0c;Ansible 的 yum 模块 和 SaltStack 的 pkg 模块 功能相似。它们都用于管理软件包&#xff0c;支持安装、升级、删除和查询等操作。 Ansible 的 yum 模块 用途&#xff1a; 专门用于基于 Red Hat …

JVM 面试题相关总结

&#x1f9d1; 博主简介&#xff1a;CSDN博客专家&#xff0c;历代文学网&#xff08;PC端可以访问&#xff1a;https://literature.sinhy.com/#/literature?__c1000&#xff0c;移动端可微信小程序搜索“历代文学”&#xff09;总架构师&#xff0c;15年工作经验&#xff0c;…

【Django】在view中调用channel来主动进行websocket通信

前提&#xff1a;consumer中已经写好了建立连接的代码&#xff0c;并且能够成功把连接加入到通道层的组内 可以参考我的另一个博客&#xff1a; LuckySheet协同编辑后端示例(DjangoChannel,Websocket通信)_lucksheet 协同编辑-CSDN博客 我是懒得去折腾luckysheet的源码&…

Java 转 C之错误处理

提纲&#xff1a; 从 Java 转向 C 的错误处理概念概述Java 异常机制与 C 返回值/errno 的对比C 中错误处理的常用方式详解 函数返回值errno 全局错误码自定义错误码setjmp/longjmp 模拟异常 常见错误码列表&#xff08;POSIX 环境为例&#xff09;Java 与 C 的错误处理示例对比…

区块链签名种类

1. eth_sign 简介&#xff1a;最早实现的签名方法&#xff0c;用于对任意数据进行签名。签名内容&#xff1a;直接对原始消息的哈希值进行签名。特点&#xff1a; 安全性较低&#xff0c;因为签名的消息没有明确的上下文或结构。很容易被滥用&#xff0c;攻击者可以伪造签名内…

AI-安全-B站

1 需求 百度-林道正-《大模型合规探索》火山引擎-林泽韬-《大模型安全挑战与防护实践》Chamd5-bayuncao-《基于RAG的AI代码审计框架》德国电信咨询有限公司-杨麟-《AI在SOC中的应用发展》360-李亚青-《以模制模&#xff0c;大模型安全的解决之道》金晴云华-富吉祥-《安全大脑在…

基于BiLSTM-CRF的中文电子病历命名实体识别

声明&#xff1a;博客未经允许禁止抄袭转载。 前言 最近有粉丝在后台私信我能不能更一篇关于命名实体识别(NER&#xff0c;Named Entity Recognition)的经典模型BiLSTM-CRF的实战文章&#xff0c;前段时间有点忙所有一直没有更新&#xff0c;趁着最近有点空&#xff0c;满足一…

k8s 优雅监控jvm及dump heap的方案探讨

背景 k8s cluster 的健康检测失败会主动重启pod&#xff0c;而大部份情况下健康检测失败都是由full gc引起的。往往发生重启时已经没有条件dump heap排查full gc的原因。 如何监控 为了避免因健康检测失败而导致的pod重启&#xff0c;我们需要实施有效的监控策略&#xff0c;这…

TPM 2.0:安全固件的新标准

得益于可信计算组 ( TCG ) 推出的全新 TPM 2.0规范&#xff0c;联网设备可以更好地抵御网络攻击&#xff0c;并且不太可能受到错误的攻击。 制造商将可信平台模块 (TPM) 附加到设备上&#xff0c;以帮助用户和管理员验证其身份、生成和存储加密密钥以及确保平台完整性。 在 T…

ensp实验-vrrp多网关配置

一、交换机与路由的配置区别 1. 角色定义交换机&#xff1a; Master 或 Backup: 交换机通常作为 Master 或 Backup 设备参与 VRRP&#xff0c;负责在主设备故障时接替其工作。路由器&#xff1a; Master 或 Backup: 路由器同样可以作为 Master 或 Backup 设备…

黑盒测试方法

‌黑盒测试是一种软件测试方法&#xff0c;它通过向系统提供输入并检查输出结果来验证系统的功能是否符合需求。‌黑盒测试主要关注软件的功能性&#xff0c;而不是其内部结构或工作原理。以下是几种常见的黑盒测试顺序方法&#xff1a; 场景设计法‌&#xff1a; 通过模拟实际…

游戏引擎学习第38天

仓库: https://gitee.com/mrxiao_com/2d_game 回顾上次的内容。 我们之前讨论了将精灵放在屏幕上&#xff0c;但颜色错误的问题。问题最终查明是因为使用了一个调整工具&#xff0c;导致文件的字节顺序发生了变化。重新运行“image magic”工具对一些大图像进行重新处理后&am…

TDengine 新功能 复合主键

1. 简介 从 TDengine 3.3.0.0 版本之后&#xff0c;新增了复合主键的功能。 TDengine 原来的时间列是不允许有重复时间戳的&#xff0c;有了复合主键功能后&#xff0c;时间列即允许有重复&#xff0c;重复后的时间戳按紧跟其后第二列主键列的值来确定唯一性。 此功能的常用…

aws(学习笔记第十六课) 使用负载均衡器(ELB)解耦webserver以及输出ELB的日志到S3

aws(学习笔记第十六课) 使用负载均衡器(ELB)以及输出ELB的日志到S3 学习内容&#xff1a; 使用负载均衡器(ELB)解耦web server输出ELB的日志到S3 1. 使用负载均衡器(ELB) 全体架构 使用ELB(Elastic Load Balancer)能够解耦外部internet访问和web server之间的耦合&#xff0c…