Redis持久化---RDB&AOF

文章详细介绍了Redis的两种持久化机制:RDB(快照)和AOF(AppendOnlyFile),包括各自的触发条件、优缺点、数据恢复方法以及混合使用场景。RDB提供全量备份,适合灾难恢复;AOF记录所有写操作,确保数据不丢失,但文件体积较大。文章还讨论了如何禁用或手动触发持久化,以及在高并发环境下可能选择的纯缓存模式。

目录

一、什么是持久化,为什么要持久化?

 二、RDB

 2.1 配置文件

2.2 自动触发

2.3 手动触发

2.4 RDB优缺点

2.5 如何修复dump.rdb文件

2.6   哪些情况会触发快照  && 如何禁用RDB?

 三、AOF

3.1  什么是AOF?

 3.2  AOF的三种写回策略

 3.3  AOF的配置

 3.4   AOF演示

 3.5 AOF恢复

3.6  AOF数据备份的优缺点

3.7  AOF的重写机制

四、RDB和AOF混合存在  与  纯缓存模式

4.1   RDB和AOF混合存在

 4.2 纯缓存模式


一、什么是持久化,为什么要持久化?

持久化就是把内存中的内容写进到磁盘当中。

因为如果数据是在内存当中的话,一旦断电(服务器宕机),那么数据都打到mysql上,这将是灾难的。

现在持久化的方式就两种:RDBAOF

 二、RDB

 什么是RDB?

 2.1 配置文件

7之前的配置

 7之后的配置

 可以看到,7之后对频次要求更高了

2.2 自动触发

我们先看一下默认的自动触发条件:

 修改配置:

这里的修改我们分成了三步:

1、我们可以在5秒内修改两次,来观察下效果:

flushall     /   flushdb命令也会直接生成dump文件,单生成的文件是空的

而且,在执行shutdown的时候,也会立刻生成一个dump文件。

我们再来观察下恢复的情况:

备注:不可以把备份文件dump.rdb和生产redis服务器放在同一台机器,必须分开各自存储

以防生产机物理损坏后备份文件也挂了

2.3 手动触发

当我们有一个比较重要的数据进来的时候,这时候还没有满足频次的要求呢,但是我们也想要保存他,为了满足这一要求,我们就可以采用手动触发的方式来进行。

生产上只能用bgsave,绝对不能和用save

因为用save阻塞redis服务器,直到持久化任务完成,相当于解决了一个问题,但又产生了一个新的问题,这是不行的

 而bgsave会在后台异步进行快照操作,不阻塞快照的同时还可以想要客户端请求该触发方式会fork一个子进程由子进程复制持久化过程

2.4 RDB优缺点

优势

(1)RDB文件紧凑,全量备份,非常适合用于进行备份和灾难恢复。

(2)生成RDB文件的时候,redis主进程会fork()一个子进程来处理所有保存工作,主进程不需要进行任何磁盘IO操作。

(3)RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快

劣势:

(1)可能会出现数据丢失:比如说还没有满足修改频次要求的时候,服务器宕机了,那么就会丢失最近一次的数据。

(2)Fork的时候,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑,可能会导致服务请求延时

2.5 如何修复dump.rdb文件

2.6   哪些情况会触发快照  && 如何禁用RDB?

哪些情况会触发快照?

1、符合自动触发条件

2、手动触发:save    bgsave

3、使用flushall  或者  flushdb的时候,但生成的rdb文件是空的,没有什么意义。

4、使用shutdown且没有开启AOF持久化

5、主从复制的时候,主节点自动触发

如何禁用RDB?

1、命令型修改(就这一次):

 2、配置文件修改:

 三、AOF

3.1  什么是AOF?

  • 以日志的形式来记录每个写操作,将Redis执行过的所有写指令记录下来(读操作不记录),只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
  • 默认情况下,redis是没有开启AOF的
  • 开启AOF 功能需要设置配置 : appendonly yes

 3.2  AOF的三种写回策略

 3.3  AOF的配置

生成路径配置:

 保存名称的配置:

redis 7之前,只有一个AOF文件,redis7之后引入了Mult Part AOF的设计,一共有三个文件

 3.4   AOF演示

生成持久化文件:

 3.5 AOF恢复

正常恢复:

和RDB的恢复一样,很简单的测试

 异常恢复:

情景展示:

那么遇到这种情况该怎么修复呢?

这和我们的RDB修复的情况很类似,也是用到了/usr/local/bin   下面的文件进行的

 修复完成之后,我们再次启动就正常了。

3.6  AOF数据备份的优缺点

优势

  • 更好的保护数据不丢失、性能高、可做紧急恢复
  • AOF有  “减肥”  机制,当AOF文件过大的时候,能够在后台自动重写(减肥)。
  • 当不小心执行了fluhall命令后,我们也可以通过将incr文件的最后一条flushall删除就行了。

劣势

  • 相同数据集的数据而言aof文件要远大于rdb文件,恢复速度慢于rdb
  • aof运行效率要慢于rdb,每秒同步策略效率较好,不同步效率和rdb相同

3.7  AOF的重写机制

一句话概括就是:

启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集,就是“减肥计划”

重写案例:

 触发条件:

 触发演示:

 我们首先肯定要修改触发条件,默认的64M我们肯定是实现不了的。

我们先来看下自动触发:

 手动触发:

重写原理:

四、RDB和AOF混合存在  与  纯缓存模式

4.1   RDB和AOF混合存在

混合存在时候的流程:

 我们应该是用到混合存在的手段,而不是单独用其中一个,就像鸳鸯锅一样

 4.2 纯缓存模式

我们要知道,redis最主要的工作就是缓存的工作,是为了来保护mysql的,开启持久化功能的时候势必会让redis分心,

有时候在高并发、高性能的缓存服务器条件下我们会为了效率,关闭持久化功能,只是让redis进行缓存功能

关闭功能的手段:         我们只是禁用了自动触发的部分,但是我们还是可以手动触发

<think> 嗯,用户这次想了解Redis配置参数aof-use-rdb-preamble的具体含义。看来用户正在研究Redis持久化机制,特别是AOF重写相关的优化配置。从用户引用的资料看,ta已经查阅了官方文档和技术博客,但需要更清晰的解释。 用户提供的引用内容很有价值。引用[1]直接来自Redis配置文件注释,说明该参数启用时AOF文件由[RDB数据][AOF日志]两部分组成。引用[2][3]补充了背景:AOF文件会因记录所有写操作而膨胀,且包含大量过期数据,重写能优化这个问题。引用[4]则确认这是Redis 4.0引入的混合持久化方案。 需要重点向用户解释清楚三点:第一,这个参数控制AOF重写时是否采用混合格式;第二,这种格式如何提升效率(加载速度+重写性能);第三,与普通AOF文件的区别。用户在引用[3]提到过期数据问题,可以关联说明混合格式如何解决这个问题——RDB部分直接存储最终数据,自然过滤了无效操作。 考虑到用户可能是运维或开发人员,准备在回答中加入配置示例(aof-use-rdb-preamble yes)和文件结构示意图。生成的问题要覆盖参数原理(为什么快)、适用场景(何时开启)、版本差异等实用角度。用户似乎关注性能优化,所以相关问题也侧重调优方向。 </think> `aof-use-rdb-preamble` 是 Redis 中用于优化 **AOF 持久化机制** 的关键参数,其核心含义和工作原理如下: ### 含义解释 1. **启用混合持久化格式** 当该参数设置为 `yes`(Redis 4.0+ 默认值)时,Redis 在执行 **AOF 重写(AOF rewrite)** 后生成的新 AOF 文件将采用 **「RDB + AOF」的混合格式**: $$ \text{[RDB 二进制数据]} + \text{[增量 AOF 日志]} $$ 文件开头是完整的 RDB 格式快照数据,后面追加新的 AOF 命令日志[^1][^2]。 2. **解决传统 AOF 痛点** - **传统 AOF 问题**:原始 AOF 文件记录所有写命令,随着运行时间增长,文件会过大且包含大量已过期或无效操作(如已删除的数据),导致恢复效率低下[^3]。 - **混合格式优势**:RDB 部分提供 **紧凑的数据快照**,直接存储内存最终状态;后续 AOF 部分仅记录快照生成后的 **增量修改**,显著减小文件体积[^1][^3]。 ### 核心作用 1. **加速重写过程** RDB 格式的生成速度远快于重写等效的 AOF 命令,大幅缩短重写耗时,减少对主线程的阻塞[^2][^4]。 2. **提升恢复效率** Redis 重启加载时: - 识别文件开头的 `REDIS` 标识符,**快速加载 RDB 部分**恢复基础数据集。 - 再应用后续的 AOF 命令进行增量同步,比解析完整 AOF 文件快数倍[^1][^4]。 3. **兼容性与灵活性** 混合格式文件仍以 `.aof` 为后缀,Redis 自动识别处理,对用户透明。同时也支持纯 RDB 或纯 AOF 持久化[^4]。 ### 配置建议 ```bash # redis.conf 配置示例 aof-use-rdb-preamble yes # 启用混合格式(推荐) appendonly yes # 开启 AOF 持久化 ``` - **适用版本**:Redis 4.0 及以上[^2][^4]。 - **性能权衡**:在数据安全(`appendfsync always`)与性能(`appendfsync everysec`)间选择时,混合格式可显著降低 `always` 模式的磁盘压力[^2]。 --- ### 相关问题 1. **为什么混合格式能比纯 AOF 更快地加载数据?** (提示:RDB 的直接内存映射 vs AOF 的命令重放) 2. **在哪些场景下建议关闭 `aof-use-rdb-preamble`?** (提示:考虑版本兼容性或特殊恢复需求) 3. **AOF 重写触发条件(`auto-aof-rewrite-percentage` 和 `auto-aof-rewrite-min-size`)如何影响混合持久化?** (提示:重写频率与文件体积的关系) 4. **混合持久化如何平衡 RDB 丢失近期数据的风险与 AOF 的实时性?** (提示:RDB 快照点 + AOF 增量的设计思路)
评论 8
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值