AOF&RDB

最新推荐文章于 2025-10-29 09:11:11 发布
原创 最新推荐文章于 2025-10-29 09:11:11 发布 · 置顶 · 649 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#aof与rdb

序言

主要用于查看不同备份模式可以调优的一些方式.

  • RDB: Redis服务器在规定时间内将内存中的数据保存到指定路径的文件中,服务器重启的时候直接将RDB文件读取到内存中
  • AOF:Redis服务器以日志的形式追加所有的REDIS操作,服务器重启的时候读取AOF文件依次执行一遍.

关于RDB最主要的问题是在备份的时候.RDB备份需要fork一个线程处理,所当处理大批量的备份的时候会影响Redis服务的效率.而AOF是可以支持大批量的命令最佳且不影响Redis服务的效率cuiyoanan2000@163.com.

因为AOF文件会不断地增大.难免有命令记录不完整.以及命令沉余.所以提供能录入如下的功能:

  1. 支持redis-check-aof来进行日志修复
  2. 支持根据相关配置rewrite相关的aof文件.

RDB

RDB是Redis默认的备份方式.具体相关配置如下:


# RDB文件的名称
dbfilename dump.rdb

# 备份RDB和AOF文件存放路径
dir /usr/local/var/db/redis/

关于RDB的备份频率的调整如下:

save 900 1              #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。

save 300 10            #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。

save 60 10000        #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。

##当snapshot时出现错误无法继续时，是否阻塞客户端“变更操作”，“错误”可能因为磁盘已满/磁盘故障/OS级别异常等  
stop-writes-on-bgsave-error yes  

##是否启用rdb文件压缩，默认为“yes”，压缩往往意味着“额外的cpu消耗”，同时也意味这较小的文件尺寸以及较短的网络传输时间  
rdbcompression yes

AOF

相关的配置如下:


# 此选项为AOF功能的开关，默认为no，通过yes来开启aof功能
appendonly yes
# 指定AOF文件名称
appendfilename appendonly.aof
# 备份RDB和AOF文件存放路径
dir /usr/local/var/db/redis/

aof的备份模式为:

appendfsync always     #每次有数据修改发生时都会写入AOF文件。

appendfsync everysec  #每秒钟同步一次，该策略为AOF的缺省策略。

appendfsync no          #从不同步。高效但是数据不会被持久化。

##aof文件rewrite触发的最小文件尺寸(mb,gb),只有大于此aof文件大于此尺寸是才会触发rewrite，默认“64mb”，建议“512mb”  
auto-aof-rewrite-min-size 64mb  

##相对于“上一次”rewrite，本次rewrite触发时aof文件应该增长的百分比。  
##每一次rewrite之后，redis都会记录下此时“新aof”文件的大小(例如A)，那么当aof文件增长到A*(1 + p)之后  
##触发下一次rewrite，每一次aof记录的添加，都会检测当前aof文件的尺寸。  
auto-aof-rewrite-percentage 100

RDB与AOF混合(redis5是默认开启的)

混合模式仍然是用的AOF的处理流程,不同的是保存的内容是 RDB与AOF的混合.简单的说：新的AOF文件前半段是RDB格式的全量数据后半段是AOF格式的增量数据.具体的流程如下所示:

  1. fork出的子进程先将共享的内存副本全量的以RDB方式写入aof文件
  2. 然后在将重写缓冲区的增量命令以AOF方式写入到文件--该出的缓冲区为备份redis时收到的Redis命令cuiyaonan2000@163.com
  3. 写入完成后通知主进程更新统计信息，并将新的含有RDB格式和AOF格式的AOF文件替换旧的的AOF文件
  4. 配置文件中开启的方式:aof-use-rdb-preamble:true


 

深入学习 Redis - 谈谈你对 Redis 的 RDB、AOF、混合持久化的了解吧？
CYK_byte的博客
08-05 2054
bgsave 操作流程是通过 fork 创建子进程，让子进程来完成持久化操作~ 持久化就会把要生成的快照数据先保存到一个临时文件中，当这个快照生成完后，再删除之前的 rdb 文件，把新生成临时 rdb 文件名字改成刚才的删除的 rdb 文件的名字，然后使用新的文件替换旧的文件（rdb 对于 fork 之后的新数据，就置之不理了，这里要对比着 aof 来看）.Ps：这后台处理是怎么做到的？并非如此，实际上这是一个 并发编程 的场景，此处 redis 使用的是 “多进程” 的方式来完成并发编程。
Redis的RDB和AOF详解
热门推荐
私聊前往站内信：https://i.youkuaiyun.com/#/msg/chat/weixin_44976692
01-25 2万+
通过本博客，我们详细了解了Redis中RDB和AOF两种持久化机制的原理、配置和应用场景。根据实际需求，可以选择合适的持久化方式或者将它们结合使用，以保障Redis数据的安全性和可靠性。如果有任何问题或建议，请随时与我们分享。下一篇博客将继续介绍更多有关Redis的知识，敬请期待！
RDB和AOF
weixin_41276029的博客
07-07 1347
1、RDB和AOF两种持久化机制的介绍 2、RDB持久化机制的优点 3、RDB持久化机制的缺点 4、AOF持久化机制的优点 5、AOF持久化机制的缺点 6、RDB和AOF到底该如何选择 我们已经知道对于一个企业级的redis架构来说，持久化是不可减少的 企业级redis集群架构：海量数据、高并发、高可用 持久化主要是做灾难恢复，数据恢复，也可以归类到高可用的一个环节里面去 比如你redis整个挂了，然后redis就不可用了，你要做的事情是让redis变得可用，尽快变得可用 重启redis，尽快让它对外提供服
Redis持久化 (RDB,AOF)
最新发布
2302_78290720的博客
10-29 763
redis持久化的原理
Redis持久化：RDB和AOF机制详解
zhaolk的博客
08-17 4450
为什么需要持久化？Redis持久化有哪些方式呢？为什么我们需要重点学RDB和AOF？ 看了这篇文章，详细你一定有所收获
【Redis】深入理解 Redis 持久化机制 —— RDB 和 AOF
qq_61635026的博客
09-15 6763
虽然 Redis 是一个内存数据库，但由于各种原因，如 Redis 服务器的重启、意外崩溃等，内存中的数据可能会丢失。为了确保数据的持久性和可靠性，Redis引入了持久化机制，允许将数据定期保存到磁盘中，以便在下次启动 Redis 时能够恢复原来的数据到内存中。 Redis 的持久化机制是 Redis 数据库的一个重要组成部分，它允许将内存中的数据以不同的方式写入磁盘，以防止数据丢失。这对于许多应用场景非常关键，特别是需要长期保存数据或具有高可用性要求的系统。
Redis 两种持久化方式 AOF 和 RDB
AliceNo的博客
11-27 2283
通常情况下，可以同时使用 RDB 和 AOF，以兼顾数据恢复的速度和可靠性。如果需要在故障时最小化数据丢失，并且对于恢复速度有较高的要求，可以使用 AOF 持久化。如果对于备份和快速恢复有较高要求，可以使用 RDB 持久化。
【Redis入门到精通七】详解Redis持久化机制（AOF，RDB）
2203_75565612的博客
09-26 1295
众所周知，Redis的快主要依赖于它的数据是存储在内存当中的，数据存储和提取避免了读写硬盘这一非常耗时的操作，但是如果在运行过程中发生了进程中断，内存中的数据就会丢失，为了解决数据丢失的问题，Redis提供了RDB和AOF两种持久化机制，当Redis重启时可以利用之前持久化的文件实现数据恢复。AOF文件内因为写入的是吗命令的文本文件，随着不断的写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。校验：如果 Redis 启动时加载到损坏的 RDB ⽂件会拒绝启动。
精选资源
【大厂面试】Redis 持久化AOF、RDB概念总结
01-21
AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以 redis 协议追加保存每次写的操作到文件末尾，redis 还能对 AOF 文件进行后台重写，使得 AOF 文件的体积...
什么是RDB和AOF
完全体
04-15 1002
特性RDBAOF持久化方式定时快照记录所有写命令文件大小小（压缩二进制）大（文本命令）恢复速度快慢（需重放命令）数据安全可能丢失分钟级数据最多丢失1秒数据资源消耗高（fork进程）低（追加写入）
Redis 复制工具 支持 sync、psync、psync2 可以解析 rdb、aof、rdb 和 aof 混合文件 支持 redis-7.2.zip
12-02
备份远程rdb快照3.3. 备份远程命令3.4. 转换rdb为dump格式3.5. Rdb 检查3.6. 扫描和 PSYNC3.7. 其他例子4. 高级主题4.1. 命令扩展4.1.1. 编写命令4.1.2. 编写命令解析器4.1.3. 注册此解析器4.1.4. 处理命令事件...
AOF和RDB
qq_42430080的博客
05-20 1023
AOF和RDB都是redis的两种持久化的方式 两种区别： AOF的优缺点： -优点： 同步性好，实时，每秒，不同步 缺点：速度慢于RDB及占用空间大 总结： RDB用于对数据的完整性要求不是太高 AOF的完整性更好，但性能不如RDB 如果只做缓存，可以不用做任何储存 这两种模式可以混合1使用 Master-Slave可实现高可用 ...
RDB、AOF详解及优缺点总结
qq_15762065的博客
09-10 5286
redis持久化 redis虽然是一个内存级别的缓存程序，也就是redis是使用内存进行数据的缓存的，但是其可以将内存的数据按照一定的策略保存到磁盘上，从而实现数据持久保存的目的 目前redis支持两种不同方式的数据持久保存机制，分别是RDB和AOF 其中RDB类似于Mysql dump快照，AOF则类似与mysql binlog 1.RDB模式 RDB（Redis DataBase）：基于时间的快照，其默认只保留当前最小异常的快照，特点是执行速度比较快，缺点是可能会丢失上次快照到当.
Redis持久化的两种方式：RDB与AOF（详解）
PeaK欢迎大家评论留言，一起交流Java技术
10-24 6039
Redis为什么要持久化机制，RDB和AOF两者有什么特点，两者如何抉择？
Redis的持久化——AOF与RDB
小羽毛的博客
07-30 570
一、概述 Redis支持AOF与RDB两种持久化机制。持久化可有效的避免因进程退出而造成的数据丢失问题。持久化可以让用户将自己的数据存储在硬盘上，当重启时，根据持久化的数据即可实现数据恢复。 Redis常用配置说明：https://www.redis.net.cn/tutorial/3504.html。 二、AOF AOF(Ap...
Redis 持久化机制：AOF 与 RDB 详解
dnuiking的博客
03-17 1795
Redis 是基于内存型的 NoSQL，和 MySQL 是不同的，使用内存存储进行数据缓存。如果想要实现数据的持久化，Redis 也可支持将内存数据保存到硬盘文件中。以MySQL 做类比RDB类似MySQL dump，AOF类似 MySQL binlog。
深入解析 Redis 的两种持久化机制：RDB 与 AOF
2401_87398486的博客
09-27 971
Redis提供RDB和AOF两种持久化机制：RDB通过快照实现全量备份，恢复快但可能丢失数据；AOF记录写命令实现增量持久化，数据更安全但恢复较慢。核心差异在于RDB适合对一致性要求低的缓存场景，AOF适合核心业务。建议线上采用混合模式（Redis4.0+），结合两者优势。选择时需权衡数据安全性与性能需求，并配合硬件配置与备份策略构建完整的数据保护方案。
一篇文章带你了解Redis持久化机制（RDB、AOF）
qq_38196449的博客
06-19 1229
利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化。说白了Redis是基于内存的，快是快，但一关机数据就没了，这样肯定不行啊，所以就要把数据都存在磁盘上，这个操作就叫持久化。为什么要持久化？防止数据的意外丢失，确保数据安全性。哪有服务器一宕机数据就没的，这谁还用Redis？是redis的默认持久化机制。RDB相当于照快照，保存的是一种状态。几十G数据 —>几kb快照。快照是默认的持久化方式，这种方式就是将内存中数据以快照的方式写入到二进制。
Redis的持久化 AOF和RDB
Qiuyuguohou的博客
03-18 3150
Redis的持久化 前言：此文章是学习Redis 核心技术与实战时做的学习笔记，仅供学习和参考。 Redis如何避免数据丢失？ Redis用作缓存时，数据存储在内存中。一旦服务器宕机，内存中的数据就会全部丢失。 一个解决方案是从数据库中恢复数据，但是存在两个问题：1、数据库中的数据是存储在硬盘中的，存取速度相对于内存来说太慢，大大影响了Redis的性能；2、频繁读取数据会给数据库增加压力； 因此Redis拥有自己的持久化机制，即 AOF（Append Only File）日志和 RDB 快照。 AOF日志
Aof 和rdb
08-14
<think>我们正在讨论Redis的持久化机制，特别是RDB和AOF。根据用户的问题，需要详细解释两者的区别与原理，并参考提供的引用内容。同时，用户之前的问题是关于Redis的拒绝策略、过期策略和删除策略，但当前问题转向了持久化机制，因此我们需要专注于AOF和RDB。 引用内容摘要： [1]：介绍了RDB和AOF的基本概念，包括RDB的bgsave机制（写时复制）、RDB的优点和缺点，AOF的持久化过程、刷盘策略、重写、优点和缺点，以及混合持久化。 [2]：强调RDB像“快照”，适合快速恢复和冷备份；AOF像“操作日志”，适合数据完整性要求高的场景。 [3]：指出选择标准是看系统是否愿意牺牲性能换取更高一致性（AOF），还是愿意在写操作频繁时禁用备份换取性能（RDB），并提到RDB具有最终一致性。 [4]：说明RDB不够耐久，可能会丢失最近写入的数据，而AOF是更耐久的持久化方式。 回答结构： 1. 简要介绍Redis持久化的概念和两种机制（RDB和AOF）。 2. 分别详细说明RDB和AOF的原理。 3. 对比两者的区别（包括持久化方式、数据安全性、性能、恢复速度、文件大小等）。 4. 介绍Redis 4.0的混合持久化。 5. 如何选择RDB和AOF。 6. 生成相关问题。 注意：根据用户要求，使用LaTeX格式表示数学表达式（如果有的话），但本主题可能较少涉及数学公式，但如果有需要，比如涉及一些算法描述，会使用。另外，引用标识要自然地添加在引用内容的末尾。 由于用户要求生成相关问题，我们将在最后提出几个相关问题。 开始回答：</think>### Redis持久化机制：RDB与AOF的原理与深度对比 #### 1. **Redis持久化核心目标** - 解决内存数据易失性问题，确保**故障恢复时数据不丢失** - 两种互补机制：**RDB（快照）** 和 **AOF（日志追加）** - 关键指标：数据安全性、性能开销、恢复速度[^1][^2] --- #### 2. **RDB（Redis DataBase）原理** **工作流程** ```mermaid graph LR A[触发条件] --> B[创建子进程] B --> C[父进程继续处理请求] B --> D[子进程写入数据到临时RDB文件] D --> E[原子替换旧RDB文件] ``` - **核心机制**： - **写时复制（COW）**：子进程复制父进程内存页表，仅当父进程修改数据时才复制物理内存[^1] - **触发条件**： - 手动执行 `SAVE`（阻塞主线程）或 `BGSAVE`（后台异步） - 配置文件定时策略（如 `save 900 1`） - 关闭服务器时自动触发 **特性对比** | 优点 | 缺点 | |------|------| | ✅ 二进制压缩文件（体积小） | ❌ 可能丢失最后一次快照后的数据[^4] | | ✅ 极速恢复（直接加载内存） | ❌ 大数据量时 `BGSAVE` 的 `fork()` 可能阻塞主线程 | | ✅ 适合冷备份与灾难恢复 | ❌ 定时触发导致数据一致性弱（最终一致）[^3] | --- #### 3. **AOF（Append Only File）原理** **工作流程** ```mermaid graph TB A[写入命令] --> B[写入AOF缓冲区] B --> C{刷盘策略} C -->|always| D[每个命令同步磁盘] C -->|everysec| E[每秒批量同步] C -->|no| F[依赖操作系统刷盘] ``` - **核心机制**： - **日志追加**：记录所有修改操作（如 `SET key value`） - **重写机制（Rewrite）**： - 基于当前数据生成新AOF文件，消除冗余命令 - 使用 `BGREWRITEAOF` 后台执行，避免阻塞 - **刷盘策略**： - `always`：每个命令刷盘（强一致，性能最低） - `everysec`：每秒批量刷盘（平衡方案，默认） - `no`：依赖操作系统刷盘（高性能，可能丢数据）[^1][^4] **特性对比** | 优点 | 缺点 | |------|------| | ✅ 数据丢失风险低（至多丢1秒数据） | ❌ 文件体积大（需定期重写） | | ✅ 操作日志可审计（便于故障追踪） | ❌ 恢复速度慢（需重放所有命令） | | ✅ 支持实时持久化（强一致性）[^3] | ❌ `always` 模式性能下降50%以上 | --- #### 4. **RDB vs AOF 核心区别** | 维度 | RDB | AOF | |------|-----|-----| | **持久化方式** | 内存快照 | 操作日志追加 | | **数据安全性** | 可能丢分钟级数据 | 至多丢1秒数据（everysec） | | **恢复速度** | ⚡️ 极快（直接加载二进制） | ⏳ 慢（需重放命令） | | **性能影响** | `fork()` 瞬间内存压力 | 持续写盘I/O压力 | | **文件体积** | 小（压缩二进制） | 大（文本日志，需重写压缩） | | **适用场景** | 灾难恢复、冷备份 | 金融交易、需强一致性场景[^2][^3] | > 💡 **决策公式**： > 数据重要性权重 $W_d$ vs 性能权重 $W_p$ > - 若 $W_d \gg W_p$ → **AOF**（如支付系统） > - 若 $W_p \gg W_d$ → **RDB**（如热点缓存） > - 折中方案：**混合持久化**（Redis 4.0+） --- #### 5. **混合持久化（Redis 4.0+）** - **原理**： ```bash [RDB头部] + [AOF增量操作] ``` - 定期生成RDB快照作为基础数据 - 后续操作追加到AOF日志 - **优势**： - 恢复速度接近RDB（直接加载快照） - 数据安全性接近AOF（保留增量操作） - **启用方式**： ```conf aof-use-rdb-preamble yes # 配置文件开启 ``` --- #### 6. **实战配置建议** 1. **通用缓存场景** ```conf save 900 1 # RDB定时备份 appendonly no # 关闭AOF ``` 2. **金融交易系统** ```conf appendonly yes appendfsync always # 强一致性 aof-use-rdb-preamble yes # 混合持久化 ``` 3. **高吞吐量服务** ```conf save "" # 禁用RDB appendonly yes appendfsync everysec # 平衡性能与安全 ``` > ⚠️ **避坑指南**： > - 避免 `SAVE` 命令在生产环境使用（阻塞主线程） > - AOF重写期间磁盘空间需预留2倍当前数据大小 > - 混合持久化需Redis 4.0+，低版本需升级[^1][^4] ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

打赏作者

cuiyaonan2000

给包烟抽吧

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

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

打赏作者

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

抵扣说明：

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

余额充值