Redis持久化

Redis作为基于内存的Key-Value存储，数据默认仅存于内存中，一旦服务器宕机或重启，数据会全部丢失。为了解决这一问题，Redis提供了两种核心的持久化机制——RDB（Redis Database）和AOF（Append Only File），通过将内存数据持久化到磁盘，保障数据在故障后可恢复。

一、Redis持久化的意义 🍂

持久化是Redis从“临时缓存”升级为“可靠数据存储”的关键特性，核心目标包括：

1. 数据恢复：服务器宕机（如断电、崩溃）后，重启时可通过持久化文件恢复数据
2. 数据备份：通过持久化文件实现数据的异地备份、迁移
3. 高可用支撑：主从复制、哨兵模式、集群模式均依赖持久化机制保障数据一致性

二、RDB持久化（基于快照的定点备份）🥝

1. 什么是RDB？

RDB（Redis Database）是Redis默认的持久化方式，核心是在指定时间间隔内，对内存中的数据集创建“快照”（Snapshot），并将快照以二进制文件（默认dump.rdb）的形式存储到磁盘。

恢复时，Redis会直接将RDB文件加载到内存，快速还原数据状态。

2. RDB的实现原理 🐦‍🔥

RDB通过“fork子进程”的方式实现快照，全程不阻塞主进程，流程如下：

1. 触发RDB持久化后，主进程fork一个子进程（共享内存数据）
2. 子进程遍历内存数据，将数据集写入临时RDB文件
3. 子进程写入完成后，用临时文件替换旧的RDB文件，持久化完成
4. 主进程全程不参与数据写入，继续处理客户端命令（写时拷贝技术保障数据一致性）

流程示意图：

简略版：

主进程 → fork子进程 → 子进程写临时RDB文件 → 替换旧RDB文件 → 持久化完成
          ↓
      继续处理客户端命令

详细版：

3. RDB的触发方式

RDB支持手动触发和自动触发两种方式，满足不同场景需求：

（1）手动触发

• SAVE命令：主进程直接执行RDB快照，期间阻塞所有客户端命令（不推荐线上使用）
• BGSAVE命令：fork子进程执行快照，主进程不阻塞（推荐线上使用）

实操示例：

# 手动触发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”。

默认配置：

# 900秒内至少1次修改
save 900 1
# 300秒内至少10次修改
save 300 10
# 60秒内至少10000次修改
save 60 10000

4. 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的核心是“追加写入+重写”，流程分为三个阶段：

1. 命令追加：客户端执行写命令后，Redis先将命令写入内存中的AOF缓冲区
2. 缓冲区同步：根据appendfsync配置，将缓冲区数据同步到磁盘AOF文件
3. 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命令（后台执行，不阻塞主进程）。

实操示例：

# 手动触发AOF重写
127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started

（2）重写原理

1. 主进程fork一个子进程；
2. 子进程遍历内存数据，生成最小命令集写入临时AOF文件
3. 重写期间，主进程将新的写命令同时写入原AOF缓冲区和重写缓冲区
4. 子进程重写完成后，主进程将重写缓冲区的命令写入临时文件，用临时文件替换原AOF文件

5. AOF的优缺点

优点：

• 数据安全性高：支持秒级数据备份（everysec模式），数据丢失风险远低于RDB
• 文件可读性强：AOF文件是文本格式，可直接查看或修改（如误操作后删除错误命令）
• 支持实时持久化：适合对数据一致性要求高的场景

缺点：

• 恢复速度慢：恢复时需重新执行所有命令，大数据量下比RDB慢
• 存储效率低：AOF文件是文本格式，未压缩，占用磁盘空间大于RDB
• 重写开销：重写时fork子进程会占用内存，且同步缓冲区数据可能短暂阻塞

四、RDB与AOF的核心对比 🤔

特性	RDB	AOF
持久化方式	定点快照（二进制文件）	增量日志（文本文件）
数据安全性	较低（可能丢失两次快照间数据）	较高（最多丢失1秒数据）
恢复速度	快（直接加载二进制文件）	慢（重新执行所有命令）
存储效率	高（压缩后体积小）	低（文本格式，体积大）
性能影响	低（仅fork时短暂阻塞）	中（同步磁盘有性能损耗）
可读性	不可读（二进制）	可读（文本命令）
适用场景	周期性备份、大数据量快速恢复	实时持久化、数据一致性要求高

---

如果我的内容对你有帮助，请 点赞 ， 评论 ， 收藏 。创作不易，大家的支持就是我坚持下去的动力！