APP正在开发中...
返回顶部
您的位置： 主页 > 数据库 > Redis >

收藏
分享到

解读Redis的持久化方式(RDB、AOF)

Redis 来源：互联网 作者：佚名 发布时间：2026-04-01 22:03:01 人浏览
摘要

一、核心概念回顾 RDB vs AOF 对比 特性 RDB (快照) AOF (日志) 原理 定时全量快照 记录每条写命令 文件格式 二进制 (.rdb) 文本日志 (.aof) 文件大小 小 大 恢复速度 快 (直接加载) 慢 (重放命令) 数据

一、核心概念回顾

RDB vs AOF 对比

特性 RDB (快照) AOF (日志)
原理 定时全量快照 记录每条写命令
文件格式 二进制 (.rdb) 文本日志 (.aof)
文件大小 小 大
恢复速度 快 (直接加载) 慢 (重放命令)
数据完整性 可能丢失快照间数据 可做到秒级甚至实时
性能影响 快照时 fork 子进程 持续写磁盘，有开销

二、同时开启 RDB+AOF 的工作机制

1. 写入流程（双写机制）

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

┌─────────────────────────────────────────────────────────────────┐

│                    Redis 写操作流程                              │

└─────────────────────────────────────────────────────────────────┘

?

        写命令 (SET/DEL/HSET...)

                ↓

        ┌───────────────┐

        │   内存数据     │ ← 立即执行

        └───────┬───────┘

                │

        ┌───────┴───────┐

        ↓               ↓

┌──────────────┐  ┌──────────────┐

│    RDB 快照   │  │    AOF 日志   │

│ (定时触发)    │  │  (实时追加)   │

│ .rdb 文件     │  │  .aof 文件    │

└──────────────┘  └──────────────┘

关键点：

  • RDB：按配置的时间间隔触发（如 900 秒有 1 次修改）

  • AOF：每条写命令都记录（根据 fsync 策略决定何时落盘）

2. 混合持久化（Redis 4.0+ 核心特性）

这是最重要的配置！Redis 4.0 引入了 AOF-RDB 混合持久化：

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

┌─────────────────────────────────────────────────────────────────┐

│                    混合持久化文件格式                            │

└─────────────────────────────────────────────────────────────────┘

?

appendonly.aof 文件结构：

┌─────────────────────────────────────────────────────────────────┐

│  头部：RDB 格式快照数据 (全量数据)                               │

│  ─────────────────────────────────────────────────────────────  │

│  尾部：AOF 格式增量命令 (RDB 之后的写操作)                        │

│  ─────────────────────────────────────────────────────────────  │

│  结尾：EOF 标记                                                  │

└─────────────────────────────────────────────────────────────────┘

?

优势：

? 恢复时先加载 RDB 快照（快）

? 再重放少量 AOF 增量命令（数据完整）

? 兼顾速度和完整性

配置项：

1

2

# redis.conf

aof-use-rdb-preamble yes    # 开启混合持久化（Redis 4.0+ 默认开启）

3. AOF 重写时的混合机制

AOF 文件会越来越大，需要定期重写（Rewrite）：

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

┌─────────────────────────────────────────────────────────────────┐

│                    AOF 重写流程                                  │

└─────────────────────────────────────────────────────────────────┘

?

重写前 appendonly.aof：

┌─────────────────────────────────────────────────────────────────┐

│ RDB 快照 │ SET k1 v1 │ SET k1 v2 │ DEL k1 │ SET k2 v2 │ ...     │

│ (旧数据) │ (重复命令很多，文件膨胀)                               │

└─────────────────────────────────────────────────────────────────┘

                          ↓ BGREWRITEAOF 触发

重写后 appendonly.aof：

┌─────────────────────────────────────────────────────────────────┐

│      RDB 快照 (当前最新数据)      │  SET k2 v2  │  (增量命令)    │

│      (紧凑二进制)                │  (少量新命令)                 │

└─────────────────────────────────────────────────────────────────┘

?

结果：

? 文件体积大幅减小

? 恢复速度更快

? 数据不丢失

三、重启恢复优先级

恢复顺序规则

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

┌─────────────────────────────────────────────────────────────────┐

│                    Redis 重启恢复流程                            │

└─────────────────────────────────────────────────────────────────┘

?

                    Redis 启动

                        ↓

            ┌───────────────────────┐

            │  检查持久化文件是否存在  │

            └───────────┬───────────┘

                        │

        ┌───────────────┼───────────────┐

        ↓               ↓               ↓

   ┌─────────┐    ┌─────────┐    ┌─────────┐

   │ AOF 存在 │    │ 仅 RDB  │    │ 都无    │

   └────┬────┘    └────┬────┘    └────┬────┘

        │              │              │

        ↓              ↓              ↓

   优先用 AOF     用 RDB 恢复    空数据库

   (数据更完整)   (快照数据)    (无历史数据)

        │              │              │

        └──────────────┴──────────────┘

                       ↓

              ┌─────────────────┐

              │   恢复完成      │

              │   对外提供服务   │

              └─────────────────┘

核心原则：

  • AOF 优先级 > RDB 优先级
  • 原因：AOF 数据通常比 RDB 更完整（丢失数据更少）

四、生产环境配置推荐

完整配置示例

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

# ==================== RDB 配置 ====================

dbfilename dump.rdb                    # RDB 文件名

dir /var/lib/redis                     # 数据目录

?

# 快照触发条件（满足任一即触发）

save 900 1                             # 900 秒内至少 1 个 key 变化

save 300 10                            # 300 秒内至少 10 个 key 变化

save 60 10000                          # 60 秒内至少 10000 个 key 变化

?

stop-writes-on-bgsave-error yes        # RDB 失败时停止写入

rdbcompression yes                     # 压缩 RDB 文件

rdbchecksum yes                        # 校验和

?

# ==================== AOF 配置 ====================

appendonly yes                         # 开启 AOF

appendfilename "appendonly.aof"        # AOF 文件名

?

# AOF 落盘策略（三选一）

appendfsync everysec                   # 推荐：每秒同步（性能与安全平衡）

# appendfsync always                   # 每次写都同步（最安全，性能差）

# appendfsync no                       # 由系统决定（性能最好，可能丢数据）

?

no-appendfsync-on-rewrite no           # 重写时是否禁用 fsync

auto-aof-rewrite-percentage 100        # AOF 增长 100% 时触发重写

auto-aof-rewrite-min-size 64mb         # AOF 最小 64MB 才触发重写

?

# ==================== 混合持久化 ====================

aof-use-rdb-preamble yes               # 开启混合持久化（关键！）

五、两种模式对比

模式一：传统双持久化（Redis 4.0 之前）

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

┌─────────────────────────────────────────────────────────────────┐

│                    传统双持久化                                  │

└─────────────────────────────────────────────────────────────────┘

?

文件结构：

┌─────────────────────┐    ┌─────────────────────────────────┐

│   dump.rdb          │    │   appendonly.aof                │

│   (独立 RDB 文件)     │    │   (纯 AOF 日志，无 RDB 前缀)      │

│   全量快照          │    │   所有写命令                    │

└─────────────────────┘    └─────────────────────────────────┘

?

恢复时：

1. 优先加载 AOF 文件

2. 逐条重放所有命令

3. RDB 文件仅作为备份

?

缺点：

? AOF 文件大

? 恢复慢

? 两份文件独立管理

模式二：混合持久化（Redis 4.0+ 推荐）

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

┌─────────────────────────────────────────────────────────────────┐

│                    混合持久化                                    │

└─────────────────────────────────────────────────────────────────┘

?

文件结构：

┌─────────────────────────────────────────────────────────────────┐

│   appendonly.aof (唯一持久化文件)                                │

│   ┌─────────────────┬───────────────────────────────────────┐   │

│   │   RDB 快照部分   │   AOF 增量命令部分                     │   │

│   │   (二进制格式)   │   (文本命令格式)                       │   │

│   │   基础数据      │   RDB 之后的写操作                     │   │

│   └─────────────────┴───────────────────────────────────────┘   │

└─────────────────────────────────────────────────────────────────┘

?

恢复时：

1. 加载 RDB 快照部分（快速）

2. 重放 AOF 增量命令（少量）

3. dump.rdb 文件不再使用

?

优点：

? 恢复速度快

? 数据完整性高

? 文件管理简单

六、实际场景演示

场景：Redis 重启恢复

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

时间线：

T0: Redis 启动，开启 RDB+AOF 混合持久化

T1: 写入 100 万条数据

T2: 触发 RDB 快照 → dump.rdb 生成

T3: AOF 持续记录写命令

T4: AOF 重写 → appendonly.aof 包含 RDB 快照 + 增量命令

T5: Redis 宕机

T6: Redis 重启

?

恢复过程：

┌─────────────────────────────────────────────────────────────────┐

│  步骤 1: 检测文件                                                │

│  - 发现 appendonly.aof 存在                                     │

│  - 发现 dump.rdb 存在（但不用）                                  │

├─────────────────────────────────────────────────────────────────┤

│  步骤 2: 加载 AOF 文件                                           │

│  - 读取 RDB 前缀部分 → 恢复 100 万条基础数据 (约 2 秒)               │

│  - 重放 AOF 增量命令 → 恢复 T4-T5 期间的写操作 (约 0.5 秒)          │

├─────────────────────────────────────────────────────────────────┤

│  步骤 3: 恢复完成                                                │

│  - 总耗时约 2.5 秒                                               │

│  - 数据丢失：仅 T5 时刻未 fsync 的少量数据                        │

└─────────────────────────────────────────────────────────────────┘

?

对比纯 RDB 恢复：

- 恢复时间：约 2 秒

- 数据丢失：T2-T5 期间所有写操作（可能几小时数据）

?

对比纯 AOF 恢复：

- 恢复时间：约 30 秒+（重放所有命令）

- 数据丢失：仅 T5 时刻未 fsync 的少量数据

七、最佳实践总结

场景 推荐配置 理由
生产环境 RDB+AOF 混合持久化 性能与安全最佳平衡
高写入场景 appendfsync everysec 每秒同步，性能影响小
金融级数据 appendfsync always 不丢数据，接受性能损失
纯缓存场景 可关闭持久化 追求极致性能
Redis 版本 4.0+ 支持混合持久化

监控建议

1

2

3

4

5

6

7

8

# 检查持久化状态

redis-cli INFO persistence

?

# 关键指标：

# - rdb_last_bgsave_status: RDB 最后保存状态

# - aof_enabled: AOF 是否开启

# - aof_last_rewrite_time_sec: AOF 最后重写耗时

# - aof_current_size: AOF 当前文件大小

八、总结

问题 答案
RDB 和 AOF 能同时开吗？ 可以，且生产环境推荐同时开启
恢复时优先用哪个？ AOF 优先级更高（数据更完整）
混合持久化是什么？ AOF 文件头部存 RDB 快照，尾部存增量命令
需要配置什么？ aof-use-rdb-preamble yes（4.0+ 默认开启）
最佳实践？ Redis 4.0+ 使用混合持久化 + appendfsync everysec
Redis 4.0+ 有几个持久化文件？ 两个：dump.rdb + appendonly.aof
Redis 4.0+  appendonly.aof 内容是什么？ RDB 快照前缀 + AOF 增量命令
Redis 4.0+  dump.rdb 还会生成吗？ 会，只要 save 配置生效
Redis 4.0+   dump.rdb 有什么用？ 备份、降级兼容、手动恢复
Redis 4.0+   能删除 dump.rdb 吗？ 可以，但不推荐（失去备份）
Redis 4.0+   如何只保留一个文件？ 配置 save "" 禁用 RDB（不推荐）
Redis 版本 持久化模式 dump.rdb appendonly.aof 恢复时使用哪个
4.0 之前 仅 RDB ? 存在 ? 不存在 RDB
4.0 之前 仅 AOF ? 不存在 ? 存在 AOF
4.0 之前 RDB+AOF ? 存在 ? 存在 AOF（优先）
4.0+ 混合持久化 ? 存在 ? 存在 AOF（含 RDB 前缀）

核心要点：

  • Redis 4.0+ 的混合持久化是生产环境的标准配置，它巧妙地将 RDB 的快速恢复和 AOF 的数据完整性结合起来，通过单一的 AOF 文件同时存储快照和增量日志，实现了性能和安全的最优平衡。
  • Redis 4.0+ 混合持久化后，dump.rdb 和 appendonly.aof 两个文件都会存在。dump.rdb 虽然恢复时不用，但仍然作为独立备份存在，提供降级兼容和冷备能力。appendonly.aof 才是真正用于恢复的主文件（包含 RDB 快照 + 增量命令）。
版权声明 : 本文内容来源于互联网或用户自行发布贡献，该文观点仅代表原作者本人。本站仅提供信息存储空间服务和不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权， 违法违规的内容， 请发送邮件至2530232025#qq.cn(#换@)举报，一经查实，本站将立刻删除。

您可能感兴趣的文章 :

原文链接 :
相关文章
  • 解读Redis的持久化方式(RDB、AOF)
    一、核心概念回顾 RDB vs AOF 对比 特性 RDB (快照) AOF (日志) 原理 定时全量快照 记录每条写命令 文件格式 二进制 (.rdb) 文本日志 (.aof) 文件大

  • Redis的主从复制机制以及主从复制的实现方法

    Redis的主从复制机制以及主从复制的实现方法
    很多企业都没有使用 Redis 的集群，但是至少都做了主从。有了主从，当主节点(Master) 挂掉的时候，运维让从节点 (Slave) 过来接管，服务就可
  • 基于Redis实现登录功能思路介绍(手机号+验证码
    本文使用的是手机号＋验证码的登录方式，其中验证码是通过在控制台输出，并没有真的发送到手机上（太麻烦，主要目的还是学习使用R
  • redis中session会话共享的三种方案
    在分布式系统架构中，用户请求可能被负载均衡器分发到不同的服务器节点。如果用户的第一次请求落在服务器A并创建了Session，而第二次请
  • shell脚本批量导出redis key-value方式
    1 背景 需求：工作中需要导出线上redis数据，但需避免使用keys命令全量扫描，导致瞬间响应卡顿，从而引发超时等问题 方法：最安全的方式

  • redis通用配置类的使用

    redis通用配置类的使用
    redis通用配置类 作用 处理Springboot使用 RedisTemplate过程中的编码问题 现象如下，看数据的时候不方便 所以添加一下的配置类之后，就可以了
  • linux部署redis集群遇到的问题及解决
    版本信息： redis：5.0.8 linux服务器：CentOS 7 不同版本问题处理方式可能有所不同 1、在java程序中，连接不上redisCluster 报错信息： no reachable

  • Redis中对大Key进行处理方式

    Redis中对大Key进行处理方式
    什么是大key 很多铁子可能会认为大key，是这个key的值很大其实不是，而是key的value值很大一般对于下面这些我们可以称为大key. String 类型值
  • 一文浅析如何在Redis中实现缓存功能
    Redis 是一种高性能的键值存储系统，广泛用于实现缓存功能。它通过将数据存储在内存中，能够快速读写数据，从而显著提高应用程序的性
  • Redis Cluster模式配置
    分片 一、分片的本质与核心价值 问题根源 单机 Redis 存在内存容量和吞吐量瓶颈，分片通过将数据分散到多个节点解决此问题。 核心价值
推荐阅读
最新更新
友情链接
  • 本站所有内容来源于互联网或用户自行发布，本站仅提供信息存储空间服务，不拥有版权，不承担法律责任。如有侵犯您的权益，请您联系站长处理！
  • Copyright © 2017-2022 F11.CN All Rights Reserved. F11站长开发者网 版权所有 | 苏ICP备2022031554号-1 | 51LA统计