redis(12)持久化操作-RDB

Redis的RDB持久化通过创建数据集的快照来保存状态,使用Fork技术在后台异步执行,保证主进程高性能。RDB适合大规模恢复,但可能丢失最后一次快照后的数据。在60秒内有10000个key变化时,会自动触发bgsave。这种方式在数据完整性和一致性要求不高的场景下更优。

前言

Redis 提供了 2 个不同形式的持久化方式:

  • RDB(Redis DataBase)

  • AOF(Append Of File)

RDB

指定的时间间隔内将内存中的数据集快照写入磁盘, 也就是行话讲的 Snapshot 快照,它恢复时是将快照文件直接读到内存里。

备份是如何执行的

Redis 会单独创建(fork)一个子进程来进行持久化,首先会将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何 IO 操作的,这就确保了极高的性能。如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那 RDB 方式要比 AOF 方式更加的高效。RDB 的缺点是最后一次持久化后的数据可能丢失

Fork

  • Fork 的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量、环境变量、程序计数器等) 数值都和原进程一致,但是是一个全新的进程,并作为原进程的子进程。

  • 在 Linux 程序中,fork () 会产生一个和父进程完全相同的子进程,但子进程在此后多会 exec 系统调用,出于效率考虑,Linux 中引入了 “写时复制技术”

  • 一般情况父进程和子进程会共用同一段物理内存,只有进程空间的各段的内容要发生变化时,才会将父进程的内容复制一份给子进程。

RDB 持久化流程

 

dump.rdb 文件

rdb的默认配置文件名称为dump.rdb

rdb文件的保存路径,默认为 Redis 启动时命令行所在的目录下 “dir ./”,也可以自己修改

如何触发 RDB 快照-根据配置的策略

默认的配置策略如下图:

举例:save 60 10000,意思是在60s内生成了10000个key,那么redis就会以rbd的方式持久化数据,会先将数据保存在临时文件中,然后用临时文件替换掉当前的dump.rdb

命令 save VS bgsave

上面的例子使用的是save保存方式,redis中更推荐bgsave保存方式

  • save :save 时只管保存,其它不管,全部阻塞。手动保存,不建议。

  • bgsave:Redis 会在后台异步进行快照操作, 快照同时还可以响应客户端请求。

  • 可以通过 lastsave 命令获取最后一次成功执行快照的时间。

rdb持久化的优势

  • 适合大规模的数据恢复

  • 对数据完整性和一致性要求不高更适合使用

  • 节省磁盘空间

  • 恢复速度快

 

rdb持久化的劣势

  • Fork 的时候,内存中的数据被克隆了一份,大致 2 倍的膨胀性需要考虑。

  • 虽然 Redis 在 fork 时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。

  • 在备份周期在一定间隔时间做一次备份,所以如果 Redis 意外 down 掉的话,就会丢失最后一次快照后的所有修改。

总结

<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 增量的设计思路)
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值