🌈 个人主页: Hygge_Code
🔥 热门专栏:从0开始学习Java | Linux学习| 计算机网络
💫 个人格言: "既然选择了远方，便不顾风雨兼程"
文章目录
- Redis持久化
-
- [一、Redis持久化的意义 🍂](#一、Redis持久化的意义 🍂)
- 二、RDB持久化（基于快照的定点备份）🥝
- 三、AOF持久化（基于日志的增量备份）🥝
- [四、RDB与AOF的核心对比 🤔](#四、RDB与AOF的核心对比 🤔)
Redis持久化
|----------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Redis作为基于内存的Key-Value存储，数据默认仅存于内存中，一旦服务器宕机或重启，数据会全部丢失。为了解决这一问题，Redis提供了两种核心的持久化机制 ------RDB（Redis Database）和AOF（Append Only File），通过将内存数据持久化到磁盘，保障数据在故障后可恢复。 |
一、Redis持久化的意义 🍂
持久化是Redis从"临时缓存"升级为"可靠数据存储"的关键特性，核心目标包括：
- 数据恢复：服务器宕机（如断电、崩溃）后，重启时可通过持久化文件恢复数据
- 数据备份：通过持久化文件实现数据的异地备份、迁移
- 高可用支撑：主从复制、哨兵模式、集群模式均依赖持久化机制保障数据一致性
二、RDB持久化（基于快照的定点备份）🥝
1. 什么是RDB？
RDB（Redis Database）是Redis默认的持久化方式，核心是在指定时间间隔内，对内存中的数据集创建"快照"（Snapshot） ，并将快照以二进制文件（默认dump.rdb）的形式存储到磁盘。
恢复时，Redis会直接将RDB文件加载到内存，快速还原数据状态。
2. RDB的实现原理 🐦🔥
RDB通过"fork子进程"的方式实现快照，全程不阻塞主进程，流程如下：
- 触发RDB持久化后，主进程fork一个子进程（共享内存数据）
- 子进程遍历内存数据，将数据集写入临时RDB文件
- 子进程写入完成后，用临时文件替换旧的RDB文件，持久化完成
- 主进程全程不参与数据写入，继续处理客户端命令（写时拷贝技术保障数据一致性）
流程示意图：
简略版：
主进程 → fork子进程 → 子进程写临时RDB文件 → 替换旧RDB文件 → 持久化完成
↓
继续处理客户端命令详细版：
3. RDB的触发方式
RDB支持手动触发 和自动触发两种方式，满足不同场景需求：
（1）手动触发
SAVE命令：主进程直接执行RDB快照，期间阻塞所有客户端命令 （不推荐线上使用）BGSAVE命令：fork子进程执行快照，主进程不阻塞 （推荐线上使用）
实操示例：
redis
# 手动触发BGSAVE（后台执行，不阻塞）
127.0.0.1:6379> BGSAVE
Background saving started
# 查看最后一次RDB执行时间
127.0.0.1:6379> LASTSAVE
(integer) 1771143177 # 时间戳（2）自动触发
通过Redis配置文件（redis.conf）中的save指令设置触发条件，格式为save <seconds> <changes>，表示"在seconds秒内，数据至少变化changes次，则自动执行BGSAVE"。
默认配置：
conf
# 900秒内至少1次修改
save 900 1
# 300秒内至少10次修改
save 300 10
# 60秒内至少10000次修改
save 60 100004. RDB的核心配置
| 配置项 | 作用 | 默认值 |
|---|---|---|
dbfilename |
RDB文件名称 | dump.rdb |
dir |
RDB文件存储路径 | 启动目录 |
stop-writes-on-bgsave-error |
BGSAVE失败时是否禁止主进程写操作 | yes |
rdbcompression |
是否压缩RDB文件（LZF算法） | yes |
rdbchecksum |
是否对RDB文件做校验（CRC64算法） | yes |
5. RDB的优缺点
优点：
- 恢复速度快：RDB是二进制文件，加载时直接映射到内存，比AOF恢复快10倍以上
- 存储效率高：RDB文件经过压缩，占用磁盘空间小于AOF文件
- 不影响主进程性能：BGSAVE通过子进程执行，主进程仅fork时短暂阻塞
缺点：
- 数据丢失风险：仅保留最后一次快照的数据集，若宕机发生在两次快照之间，期间修改的数据会丢失（如60秒内触发一次，可能丢失60秒数据）
- fork子进程开销：数据量较大时，fork子进程会占用大量内存（写时拷贝），可能导致主进程短暂阻塞
- 不适合实时持久化：无法实现"秒级"数据备份，适合周期性备份场景
三、AOF持久化（基于日志的增量备份）🥝
1. 什么是AOF？
AOF（Append Only File）是Redis的增量持久化方式，核心是**将所有写命令（如SET、INCR、HSET）以Redis协议格式追加到日志文件（默认appendonly.aof）**，不修改原有文件内容。
恢复时，Redis会重新执行AOF文件中的所有写命令，还原数据状态。
2. AOF的实现原理 🐦🔥
AOF的核心是"追加写入+重写"，流程分为三个阶段：
- 命令追加：客户端执行写命令后，Redis先将命令写入内存中的AOF缓冲区
- 缓冲区同步 ：根据
appendfsync配置，将缓冲区数据同步到磁盘AOF文件 - AOF重写：AOF文件不断增大时，Redis会自动（或手动）重写文件，去除冗余命令（如多次SET同一个key合并为一次），减小文件体积
流程示意图：
简略版本：
写命令 → 写入AOF缓冲区 → 同步到AOF文件 → 定期AOF重写（优化文件体积）详细版本：
3. AOF的核心配置
AOF默认关闭，需手动开启（appendonly yes），核心配置如下：
| 配置项 | 作用 | 可选值 |
|---|---|---|
appendonly |
是否开启AOF | no（默认）/ yes |
appendfilename |
AOF文件名称 | appendonly.aof |
dir |
AOF文件存储路径 | 同RDB路径 |
appendfsync |
缓冲区同步策略 | always/everysec/no |
auto-aof-rewrite-percentage |
重写触发百分比 | 100（默认） |
auto-aof-rewrite-min-size |
重写最小文件大小 | 64mb（默认） |
关键配置说明：
appendfsync always：每次写命令都同步到磁盘，数据零丢失appendfsync everysec：每秒同步一次，最多丢失1秒数据appendfsync no：由操作系统决定同步时机，数据丢失风险最高
4. AOF重写机制
AOF文件会随写命令增多而不断增大，若不优化，可能导致磁盘空间不足、恢复速度变慢。AOF重写的核心是"合并冗余命令，生成最小命令集"。
（1）重写触发方式
- 自动触发：当AOF文件大小达到
auto-aof-rewrite-min-size，且当前大小是上次重写后大小的auto-aof-rewrite-percentage（默认100%）时，自动触发重写； - 手动触发：执行
BGREWRITEAOF命令（后台执行，不阻塞主进程）。
实操示例：
redis
# 手动触发AOF重写
127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started（2）重写原理
- 主进程fork一个子进程；
- 子进程遍历内存数据，生成最小命令集写入临时AOF文件
- 重写期间，主进程将新的写命令同时写入原AOF缓冲区和重写缓冲区
- 子进程重写完成后，主进程将重写缓冲区的命令写入临时文件，用临时文件替换原AOF文件
5. AOF的优缺点
优点：
- 数据安全性高 ：支持秒级数据备份（
everysec模式），数据丢失风险远低于RDB - 文件可读性强：AOF文件是文本格式，可直接查看或修改（如误操作后删除错误命令）
- 支持实时持久化：适合对数据一致性要求高的场景
缺点：
- 恢复速度慢：恢复时需重新执行所有命令，大数据量下比RDB慢
- 存储效率低：AOF文件是文本格式，未压缩，占用磁盘空间大于RDB
- 重写开销：重写时fork子进程会占用内存，且同步缓冲区数据可能短暂阻塞
四、RDB与AOF的核心对比 🤔
| 特性 | RDB | AOF |
|---|---|---|
| 持久化方式 | 定点快照（二进制文件） | 增量日志（文本文件） |
| 数据安全性 | 较低（可能丢失两次快照间数据） | 较高（最多丢失1秒数据） |
| 恢复速度 | 快（直接加载二进制文件） | 慢（重新执行所有命令） |
| 存储效率 | 高（压缩后体积小） | 低（文本格式，体积大） |
| 性能影响 | 低（仅fork时短暂阻塞） | 中（同步磁盘有性能损耗） |
| 可读性 | 不可读（二进制） | 可读（文本命令） |
| 适用场景 | 周期性备份、大数据量快速恢复 | 实时持久化、数据一致性要求高 |
如果我的内容对你有帮助，请 点赞 ， 评论 ， 收藏 。创作不易，大家的支持就是我坚持下去的动力！
