Redis持久化 —— RDB和AOF

最新推荐文章于 2024-11-08 22:42:46 发布
最新推荐文章于 2024-11-08 22:42:46 发布
阅读量645 收藏
点赞数
分类专栏： Redis 文章标签： redis 持久化 RDB AOF
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_52691962/article/details/134675930
版权

❤ 作者主页：欢迎来到我的技术博客😎
❀ 个人介绍：大家好，本人热衷于Java后端开发，欢迎来交流学习哦！(￣▽￣)~*
🍊 如果文章对您有帮助，记得关注、点赞、收藏、评论⭐️⭐️⭐️
📣 您的支持将是我创作的动力，让我们一起加油进步吧！！！🎉🎉

文章目录

1. RDB持久化

1.1 定义

RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。快照文件称为RDB文件，默认是保存在当前运行目录。

1.2 RDB执行时机

RDB持久化在四种情况下会执行：

  • 执行 save 命令
  • 执行 bgsave 命令
  • Redis 停机时
  • 触发 RDB 条件时

（1）save命令
执行下面的命令，可以立即执行一次RDB：

在这里插入图片描述
 
save命令会导致主进程执行RDB，这个过程中其它所有命令都会被阻塞。只有在数据迁移时可能用到。

（2）bgsave命令

下面的命令可以异步执行RDB：
在这里插入图片描述
 
这个命令执行后会开启独立进程完成RDB，主进程可以持续处理用户请求，不受影响。

（3）Redis停机时
Redis停机时会执行一次save命令，实现RDB持久化。

（4）触发RDB条件
Redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下：

# 900秒内，如果至少有1个key被修改，则执行bgsave ， 如果是save "" 则表示禁用RDB
save 900 1  
save 300 10  
save 60 10000

RDB的其它配置也可以在redis.conf文件中设置：

# 是否压缩 ,建议不开启，压缩也会消耗cpu，磁盘的话不值钱
rdbcompression yes

# RDB文件名称
dbfilename dump.rdb  

# 文件保存的路径目录
dir ./

1.3 RDB原理

bgsave 开始时会 fork 主进程得到子进程，子进程共享主进程的内存数据。完成 fork 后读取内存数据并写入 RDB 文件。

fork采用的是copy-on-write技术：

  • 当主进程执行读操作时，访问共享内存；
  • 当主进程执行写操作时，则会拷贝一份数据，执行写操作；
    在这里插入图片描述

1.4 小结

1、RDB方式bgsave的基本流程？

  • fork主进程得到一个子进程，共享内存空间
  • 子进程读取内存数据并写入新的RDB文件
  • 用新RDB文件替换旧的RDB文件

2、RDB会在什么时候执行？save 60 1000代表什么含义？

  • 默认是服务停止时
  • 代表60秒内至少执行1000次修改则触发RDB

3、RDB的缺点？

  • RDB执行间隔时间长，两次RDB之间写入数据有丢失的风险
  • fork子进程、压缩、写出RDB文件都比较耗时

2. AOF持久化

2.1 定义

AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

2.2 AOF原理

在这里插入图片描述

2.3 AOF配置

AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF：

# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"

AOF的命令记录的频率也可以通过redis.conf文件来配：

# 表示每执行一次写命令，立即记录到AOF文件
appendfsync always 
# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsync everysec 
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no

三种命令记录策略的对比：

配置项刷盘时机优点缺点
Always同步刷盘可靠性高，几乎不丢数据性能影响大
everysec每秒刷盘性能适中最多丢失1秒数据
no操作系统控制性能最好可靠性较差，可能丢失大量数据

2.4 AOF文件重写

因为是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行 bgrewriteaof 命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。

在这里插入图片描述
 

如图，AOF原本有三个命令，但是 set num 123 和 set num 666 都是对 num 的操作，第二次会覆盖第一次的值，因此第一个命令记录下来没有意义。

所以重写命令后，AOF文件内容就是：mset name jack num 666。

Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置：

# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写 
auto-aof-rewrite-min-size 64mb

3. RDB和AOF对比

RDB和AOF各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会 结合 两者来使用。

对比项RDBAOF
持久化方式定时对整个内存做快照记录每一次执行的命令
数据完整性不完整，两次备份之间会丢失相对完整，取决于刷盘策略
文件大小会有压缩，文件体积小记录命令，文件体积很大
宕机恢复速度很快慢
数据恢复优先级低，因为数据完整性不如AOF高，因为数据完整性更高
系统资源占用高，大量CPU和内存消耗低，主要是磁盘IO资源，但AOF重写时会占用大量CPU和内存资源
使用场景可以容忍数分钟的数据丢失，追求更快的启动速度对数据安全性要求较高

4. 混合持久化

开启混合持久化功能，可以在 Redis 配置文件将下面这个配置项设置成 yes：

aof-use-rdb-preamble yes
  1. 当开启了混合持久化时，在 AOF 重写日志时，fork 出来的重写子进程会先将与主线程共享的内存数据以 RDB 方式写入到 AOF 文件，然后主线程处理的操作命令会被记录在重写缓冲区里。
  2. 重写缓冲区里的增量命令会以 AOF 方式写入到 AOF 文件，写入完成后通知主进程将新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件。

使用了混合持久化，AOF 文件的前半部分是 RDB 格式的全量数据，后半部分是 AOF 格式的增量数据。

注意： 增量数据是相对于全量数据的变化部分，它记录了数据的更新、插入或删除等操作，使得在数据恢复时能够还原到最新的状态。

持久化后的AOF文件内容：
在这里插入图片描述
 
优点：

  • 重启 Redis 加载数据的时候，由于前半部分是 RDB 内容，这样加载的时候速度会很快。
  • 加载完 RDB 的内容后，才会加载后半部分的 AOF 内容，这里的内容是 Redis 后台子进程重写 AOF 期间，主线程处理的操作命令，可以使得数据更少的丢失。

缺点：

  • 混合持久化需要同时保存AOF文件和RDB文件，相对于单独使用AOF或RDB持久化方式，磁盘占用会更大。
  • 如果Redis的工作负载较高，频繁地进行写操作，AOF文件会不断增长。当AOF文件较大时，恢复时的加载时间和性能都会受到影响。
  • 如果AOF文件在写入时发生错误或者损坏，恢复过程可能无法完全恢复数据。此时，需要依赖RDB文件进行恢复，但因为RDB文件只是定期生成，所以可能会有一些数据丢失。

 
非常感谢您阅读到这里，如果这篇文章对您有帮助，希望能留下您的点赞👍 关注💖 分享👥 留言💬thanks！！！

【Redis】深入理解 Redis 持久化机制 —— RDB 和 AOF
qq_61635026的博客
09-15 4622
虽然 Redis 是一个内存数据库，但由于各种原因，如 Redis 服务器的重启、意外崩溃等，内存中的数据可能会丢失。为了确保数据的持久性和可靠性，Redis引入了持久化机制，允许将数据定期保存到磁盘中，以便在下次启动 Redis 时能够恢复原来的数据到内存中。 Redis 的持久化机制是 Redis 数据库的一个重要组成部分，它允许将内存中的数据以不同的方式写入磁盘，以防止数据丢失。这对于许多应用场景非常关键，特别是需要长期保存数据或具有高可用性要求的系统。
Redis持久化之RDB和AOF详解
m0_74293254的博客
07-30 1276
RDB 持久化利用了操作系统的 fork 和 Copy-on-Write 技术来实现数据的安全持久化。主进程在执行写操作时会进行内存页的复制，以保证主进程和子进程在写操作时不会相互影响。这种机制使得 Redis 在执行 BGSAVE 时能够保持高效和安全，确保数据在持久化到磁盘后的一致性和可靠性。
Redis持久化（RDB、AOF）详解
喻师傅的学习笔记
06-25 2866
Redis持久化机制详解
Redis持久化——RDB和AOF
Meshro的博客
03-16 278
Redis处理的每一个写命令都会记录在AOF文件中，也可看做是命令日志文件。AOF文件是以追加的方式记录接收到的写命令的，而且AOF会记录对同一个key的多次写操作，但只有。RDB是间隔一段时间进行持久化，如果持久化之间redis发生故障，会发生数据丢失。Redis内部是具有RDB的触发机制的，可以通过配置redis.conf来设置。快照文件称为RDB文件，默认是保存在当前运行目录，默认是dump.rdb。redis默认配置中AOF持久化机制是不开启的，需要在配置中开启。命令,让AOF文件执行重写功能。
Redis持久化：RDB和AOF
热门推荐
????????️的博客
05-19 1万+
一、为什么需要持久化？ Redis对数据的操作都是基于内存的，当遇到了进程退出、服务器宕机等意外情况，如果没有持久化机制，那么Redis中的数据将会丢失无法恢复。有了持久化机制，Redis在下次重启时可以利用之前持久化的文件进行数据恢复。Redis支持的两种持久化机制： RDB：把当前数据生成快照保存在硬盘上。 AOF：记录每次对数据的操作到硬盘上。 二、RDB持久化 在指定的时间间隔内将内存中的数据集快照写入磁盘，它恢复时是将快照文件直接读到内存里。 RDB（Redis DataBase）持久化是把当前R
Redis持久化：RDB和AOF的区别
qq_61504864的博客
11-23 752
AOF(Append Only File)：记录所有执行的写入命令到AOF文件中，但肯定不能每执行一条写入命令就记录到文件中，那会严重拖垮性能，于是会准备一个缓冲区，区别于这个缓冲区，操作系统也有一个缓冲区，所以我们需要通过刷新来保证正常写入，可以根据设定的参数来写入并刷新AOF文件，always: 每个事件周期都同步刷新一次。AOF重写缓冲区：如果子进程在压缩重写过程中，AOF文件有了新的写入，那么新的写入会进入缓冲区，重写结束后，缓冲区中的命令会被写入到新的AOF文件中。
Redis持久化（RDB、AOF、混合持久化）
echola_mendes的博客
08-21 1562
Redis 需要持久化主要是为了保证数据的安全性和持久性，防止数据丢失Redis 持久化功能默认是开启的，这样做的目的也是为了保证程序的稳定性，防止缓存雪崩、缓存击穿等以及保证数据不丢失。若要手动关闭 Redis 持久化，需要将 RDB、AOF 和混合持久化全部关闭才行，并且关闭之后需要重启 Redis 服务才能生效。
Redis5.0+——持久化——RDB&AOF
G_change_的博客
12-25 770
Redis5.0+——持久化——RDB&AOF
【Redis】持久化—RDB和AOF机制
qq_55119554的博客
08-12 932
Redis中RDB和AOF持久化机制！！！
Redis 持久化之RDB和AOF.doc
10-09
Redis 持久化是确保数据安全的重要机制，它提供了两种主要的方法：RDB（Redis Database）和 AOF（Append Only File）。RDB 是一种快照式的持久化方式，而 AOF 则记录每次写操作的日志。 RDB 持久化在特定条件下将...
Redis持久化 - RDB和AOF
08-17
“Redis持久化 - RDB和AOF” Redis持久化是指将数据库中的数据保存到永久存储设备中，以避免数据丢失。Redis提供了两种持久化方式：RDB（快照方式）和AOF（写日志方式）。 RDB（Redis Database）是一种快照方式的...
Redis持久化RDB和AOF区别详解
12-14
为了确保数据在服务器重启或异常情况下的安全，Redis提供了两种主要的持久化机制：RDB（Redis Database Persistence，即快照）和AOF（Append Only File，追加日志）。下面将详细解释这两种持久化方式的区别。 **RDB...
Redis持久化中RDB和AOF有哪些区别？你知道吗！
程序媛小琬的博客
05-16 1163
前言 关于Redis的知识点总结了一个思维导图分享给大家 Redis是一个内存数据库，为了保证数据不丢失，必须把数据保存到磁盘，这就叫做持久化。 Redis有两种持久化方法：RDB方式以及AOF方式。 RDB持久化 RDB持久化把内存中的数据持久化到硬盘，生成RDB文件，也就是“快照”。通过RDB文件可以重新恢复内存中的数据。RDB文件是一个压缩过的文件，因此RDB持久化的体积比AOF小，因为存储的是数据，所以恢复很快，性能好，但是可能会丢失最后一次持久化的数据。 RDB持久化机制的两种方式 显示开启
redis用法（二）
墨城的博客
11-07 938
Redis hash 是一个 string 类型的 field（字段） 和 value（值） 的映射表，hash 特别适合用于存储对象。任务，学会五大数据类型，知道一个产品，再使用redis的时候，写入的key是多少个，以及写入的key都是什么类型。Redis 有序集合和集合一样也是 string 类型元素的集合,且不允许重复的成员。Redis 中集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。集合成员是唯一的，这就意味着集合中不能出现重复的数据。大家公有的，去重的所有数据。
Redis - 事务
ketil27的博客
11-08 516
Redis 的事务和MySQL的事务概念上是类似的.都是把⼀系列操作绑定成⼀组.让这⼀组能够批量执 ⾏.弱化的原⼦性:redis没有"回滚机制".只能做到这些操作"批量执⾏".不能做到"⼀个失败就恢复到 初始状态".不保证⼀致性:不涉及"约束". 也没有回滚.MySQL的⼀致性体现的是运⾏事务前和运⾏后,结果都 是合理有效的,不会出现中间⾮法状态.不需要隔离性:也没有隔离级别,因为不会并发执⾏事务(redis单线程处理请求).
初识Redis
m0_53926113的博客
11-08 876
通常，内存数据库在性能要求高、访问频繁的系统中广泛应用，比如电商网站中的商品浏览记录，社交平台的用户会话数据等等。：因为支持丰富的数据结构、持久化、分布式等特性，Redis 更适合需要持久化的数据、复杂的操作或分布式架构的场景。在现代的应用中，数据库（如 MySQL）通常是数据存储的核心，但由于数据库的查询速度不如内存，直接访问数据库会影响应用的响应速度。由于 Redis 的内存数据库特性，它能实现对热点数据的快速响应，避免 MySQL 反复查询相同的数据，提升了用户的使用体验。
Go 使用 Redis 实现分布式锁
qq_37106501的博客
11-06 1013
Go 使用 Redis 实现分布式锁
Java版企业电子招标采购系统源码Spring Cloud + Spring Boot +二次开发+ MybatisPlus + Redis
m0_66404702的博客
11-05 412
主要功能包含：招标公告管理、变更公告管理、终止公告管理、中标候选人公告管理、中标公告管理、采购公告管理、采购结果公告管理、单一来源采购结果公告管理。3、采购项目管理：可对项目采购过程全流程管理，包含功能有：评审人员的选取/抽取、基准价维护、供应商缴费审核、投标过程记录查询、供应商报价维护、项目评审查询、线下项目管理、采购计划制定与维护。主要功能包含：公告模板管理、评审人员管理、第三方机构管理、供应商管理、采购类别设置、评审模板管理、考核模板管理。主要板块包含：招标公告、非招标公告、系统通知、政策法规。
Redis8：商户查询缓存2
最新发布
qq_63981644的博客
11-08 784
缓存穿透：是指客户端请求的数据在缓存中和数据库中都不存在，这样缓存永远不会生效，这些请求都会打到数据库。举例：假设我们的店铺id是1~20，结果有人非要查询id为100的店铺，这明显是不合理的，于是就会出现如下情况：此时缓存中没有，去数据库查询也没有，于是这个不怀好意的人抓住了这个漏洞，搞了一堆线程来发送大量的请求，查询这个不存在的id，这些海量的请求都会打到数据库中，长时间一来，数据库就会垮掉（数据库速度不像redis那么快，可能打到数据库的请求一多，就会导致数据库垮掉）。
Redis持久化：RDB与AOF详解及恢复
"Redis的两种持久化机制是RDB（Redis DataBase）和AOF（Append Only File）。RDB是默认的持久化方案，通过在指定时间间隔内保存内存中的数据快照到磁盘上的dump.rdb文件。AOF则记录每一次写操作，形成日志文件，用于...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Java技术一点通

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值