当前位置：首页 > news >正文

Redis 持久化机制详解：小白也能看懂的数据不丢方案

news 2026/5/23 12:03:26

🎯本文适合人群：Redis 初学者、后端开发工程师
⏱️阅读时长：25分钟
📌你将收获：深入理解 RDB、AOF、混合持久化，掌握数据安全保障方案

📖 目录

一、为什么需要持久化
二、RDB 快照持久化
三、AOF 日志持久化
四、RDB vs AOF 对比
五、混合持久化
六、数据恢复流程
七、持久化最佳实践
八、常见问题排查
九、常见面试题

一、为什么需要持久化

1.1 Redis 的内存特性

┌──────────────────────────────────────────┐ │ Redis 数据存储位置 │ ├──────────────────────────────────────────┤ │ │ │ 内存（RAM） │ │ ├─ 优点：读写速度极快（纳秒级） │ │ └─ 缺点：断电/重启数据丢失 ❌ │ │ │ │ 磁盘（Disk） │ │ ├─ 优点：数据持久化，不丢失 ✅ │ │ └─ 缺点：读写速度慢（毫秒级） │ │ │ │ Redis 持久化 = 内存 + 磁盘 │ │ ├─ 平时：数据在内存（快） │ │ └─ 定期/实时：备份到磁盘（安全） │ │ │ └──────────────────────────────────────────┘

1.2 没有持久化的风险

场景模拟：

# 1. 用户缓存了大量数据127.0.0.1:6379>SET user:1001"张三"OK127.0.0.1:6379>SET user:1002"李四"OK...(写入100万条数据)# 2. 服务器突然断电 💥# 3. 重启 Redis$ redis-server# 4. 数据全部丢失 ❌127.0.0.1:6379>KEYS *(empty array)

影响：

缓存数据丢失 → 大量请求打到数据库 →缓存雪崩💀
业务数据丢失 → 用户数据损失 →客户投诉😡

1.3 持久化方案概览

┌────────────────────────────────────────────────┐ │ Redis 持久化方案 │ ├────────────────────────────────────────────────┤ │ │ │ 1. RDB（Redis Database） │ │ ├─ 原理：定期生成内存快照 │ │ ├─ 文件：dump.rdb │ │ ├─ 优点：文件小、恢复快 │ │ └─ 缺点：可能丢失最后一次快照后的数据 │ │ │ │ 2. AOF（Append Only File） │ │ ├─ 原理：记录每一条写命令 │ │ ├─ 文件：appendonly.aof │ │ ├─ 优点：数据完整性高 │ │ └─ 缺点：文件大、恢复慢 │ │ │ │ 3. 混合持久化（Redis 4.0+） │ │ ├─ 原理：RDB + AOF 混合 │ │ └─ 优点：兼具 RDB 和 AOF 优点 │ │ │ └────────────────────────────────────────────────┘

二、RDB 快照持久化

2.1 工作原理

RDB = 数据库的"照片"

时间线： 10:00 ─────→ 10:05 ─────→ 10:10 ─────→ 10:15 │ │ │ │ ├─ 写入1000 ├─ 写入2000 ├─ 写入3000 ├─ 写入4000 │ 条数据 │ 条数据 │ 条数据 │ 条数据 │ │ │ │ ▼ ▼ ▼ ▼ 快照1 快照2 快照3 快照4 (dump.rdb) (覆盖) (覆盖) (覆盖) 如果 10:12 服务器宕机： └─ 恢复到 10:10 的快照3 └─ 丢失 10:10 ~ 10:12 之间的数据 ❌

2.2 触发方式

方式 1：自动触发（配置文件）

# redis.conf# 格式：save <seconds> <changes># 含义：在 seconds 秒内，如果至少有 changes 次修改，则触发 RDBsave9001# 900秒（15分钟）内，至少1次修改save30010# 300秒（5分钟）内，至少10次修改save6010000# 60秒（1分钟）内，至少10000次修改# 示例：# - 15分钟内修改了1次 → 触发# - 5分钟内修改了10次 → 触发# - 1分钟内修改了10000次 → 触发

多条件关系：满足任一条件即触发（OR 逻辑）

# 禁用自动 RDBsave""

方式 2：手动触发（命令）

# SAVE：阻塞式生成 RDB（主线程执行，会阻塞客户端）127.0.0.1:6379>SAVE OK# 期间无法处理其他命令 ⚠️# BGSAVE：后台生成 RDB（推荐，子进程执行）127.0.0.1:6379>BGSAVE Background saving started# 不阻塞 ✅# 查看最后一次 RDB 时间127.0.0.1:6379>LASTSAVE(integer)1735689600# Unix 时间戳

方式 3：自动触发（其他场景）

# 1. 执行 SHUTDOWN 命令127.0.0.1:6379>SHUTDOWN# 自动执行 SAVE，生成 RDB 后退出# 2. 主从复制时# 主节点自动生成 RDB 发送给从节点# 3. 执行 FLUSHALL127.0.0.1:6379>FLUSHALL# 生成空的 RDB（慎用！）

2.3 RDB 文件位置

# 查看 RDB 文件配置127.0.0.1:6379>CONFIG GETdir1)"dir"2)"/var/lib/redis"# RDB 文件目录127.0.0.1:6379>CONFIG GET dbfilename1)"dbfilename"2)"dump.rdb"# RDB 文件名# 完整路径：/var/lib/redis/dump.rdb

# 查看 RDB 文件$ls-lh/var/lib/redis/dump.rdb -rw-r--r--1redis redis 120M Jan110:15 dump.rdb

2.4 RDB 底层实现：fork + Copy-On-Write

流程图：

┌─────────────────────────────────────────────────┐ │ BGSAVE 执行过程 │ ├─────────────────────────────────────────────────┤ │ │ │ 1. Redis 主进程 fork 子进程 │ │ ├─ 主进程：继续处理客户端请求 │ │ └─ 子进程：遍历内存，写入 RDB 文件 │ │ │ │ 2. Copy-On-Write（写时复制） │ │ ├─ 子进程共享主进程的内存页（不复制） │ │ └─ 主进程修改数据时，才复制被修改的页 │ │ │ │ 3. 子进程生成 RDB 文件 │ │ └─ 完成后退出，主进程收到信号 │ │ │ └─────────────────────────────────────────────────┘

为什么使用 fork？

不阻塞主进程：主进程继续服务
数据一致性：子进程看到的是 fork 时刻的数据快照
内存高效：Copy-On-Write，不会完全复制内存

2.5 RDB 配置详解

# redis.conf# ========== 快照触发条件 ==========save9001save30010save6010000# ========== RDB 文件名 ==========dbfilename dump.rdb# ========== RDB 文件目录 ==========dir/var/lib/redis# ========== RDB 压缩（推荐开启）==========rdbcompressionyes# 使用 LZF 压缩，减小文件大小# ========== RDB 校验（推荐开启）==========rdbchecksumyes# 文件末尾添加 CRC64 校验码，防止损坏# ========== BGSAVE 失败是否停止写入 ==========stop-writes-on-bgsave-erroryes# yes：BGSAVE 失败时，Redis 拒绝写入（保护数据）# no：继续写入（可能丢失数据）

2.6 RDB 优缺点

优点：

文件紧凑：单个二进制文件，适合备份
恢复速度快：直接加载到内存，比 AOF 快
性能影响小：fork 子进程，主进程不阻塞
适合灾难恢复：可以定期复制 RDB 文件到远程服务器

缺点：

数据丢失风险：两次快照之间的数据可能丢失
fork 耗时：数据量大时，fork 可能耗时数秒
内存占用：Copy-On-Write 可能导致短时内存翻倍

三、AOF 日志持久化

3.1 工作原理

AOF = 记录每一条写命令

时间线： 10:00:00 → SET user:1001 "张三" ┐ 10:00:01 → SET user:1002 "李四" │ 10:00:02 → INCR counter ├─ 写入 AOF 文件 10:00:03 → LPUSH list "a" "b" │ 10:00:04 → SADD tags "Redis" ┘ appendonly.aof 文件内容： *3\r\n$3\r\nSET\r\n$9\r\nuser:1001\r\n$6\r\n张三\r\n *3\r\n$3\r\nSET\r\n$9\r\nuser:1002\r\n$6\r\n李四\r\n *2\r\n$4\r\nINCR\r\n$7\r\ncounter\r\n ... 恢复时： └─ 重新执行 AOF 文件中的所有命令

3.2 AOF 配置

# redis.conf# ========== 开启 AOF ==========appendonlyyes# 默认 no# ========== AOF 文件名 ==========appendfilename"appendonly.aof"# ========== AOF 文件目录 ==========dir/var/lib/redis# ========== AOF 同步策略（核心！）==========# appendfsync always # 每条命令都同步到磁盘（最安全，最慢）appendfsync everysec# 每秒同步一次（推荐，平衡性能和安全）# appendfsync no # 由操作系统决定（最快，最不安全）

3.3 三种同步策略对比

┌────────────────────────────────────────────────────┐ │ AOF 同步策略对比 │ ├────────────────────────────────────────────────────┤ │ │ │ 1. always（每条命令同步） │ │ ┌──────┐ ┌──────┐ ┌──────┐ │ │ │ SET │ ───→ │ AOF │ ───→ │ 磁盘 │ │ │ └──────┘ └──────┘ └──────┘ │ │ 优点：数据最安全（几乎不丢失） │ │ 缺点：性能最差（每次都等磁盘写入） │ │ 丢失：0-1 条命令 │ │ │ │ 2. everysec（每秒同步，推荐⭐） │ │ ┌──────┐ ┌──────┐ │ │ │ SET │ ───→ │ 缓冲区│ │ │ │ SET │ ───→ │ │ │ │ │ SET │ ───→ │ │ │ │ └──────┘ └──────┘ │ │ 每秒一次 ↓ │ │ ┌──────┐ │ │ │ 磁盘 │ │ │ └──────┘ │ │ 优点：平衡性能和安全 │ │ 缺点：最多丢失 1 秒数据 │ │ 丢失：1 秒内的命令 │ │ │ │ 3. no（操作系统决定） │ │ ┌──────┐ ┌──────┐ │ │ │ SET │ ───→ │ 缓冲区│ │ │ │ ... │ ───→ │ │ │ │ │ ... │ ───→ │ (很大)│ │ │ └──────┘ └──────┘ │ │ OS 决定 ↓ │ │ (可能30秒) ┌──────┐ │ │ │ 磁盘 │ │ │ └──────┘ │ │ 优点：性能最好 │ │ 缺点：可能丢失大量数据 │ │ 丢失：数秒到数十秒的命令 │ │ │ └────────────────────────────────────────────────────┘

推荐：appendfsync everysec（99.99% 的场景）

3.4 AOF 重写机制

问题：AOF 文件会越来越大

# 示例：对同一个键操作 10000 次SET count1INCR count INCR count... INCR count# 10000 次# AOF 文件记录了 10001 条命令# 但实际只需要：SET count 10001

解决方案：AOF 重写

重写前（AOF 文件）： SET user:1001 "张三" SET user:1001 "李四" ← 覆盖 SET user:1001 "王五" ← 覆盖 LPUSH list "a" LPUSH list "b" LPUSH list "c" DEL temp SET temp "new" DEL temp ← 删除 重写后（压缩）： SET user:1001 "王五" ← 只保留最终结果 RPUSH list "c" "b" "a" ← 批量命令 （temp 键已删除，不记录）

3.5 AOF 重写配置

# redis.conf# ========== 自动触发重写条件 ==========auto-aof-rewrite-percentage100# AOF 文件大小比上次重写后增长 100%，触发重写auto-aof-rewrite-min-size 64mb# AOF 文件至少达到 64MB，才触发重写# 示例：# 上次重写后 AOF 文件 64MB# 当前 AOF 文件 128MB（增长100%）→ 触发重写# 重写后可能变为 70MB# ========== 重写时是否继续写入 ==========aof-rewrite-incremental-fsyncyes# yes：重写时每 32MB 同步一次（避免阻塞）

手动触发重写：

127.0.0.1:6379>BGREWRITEAOF Background append onlyfilerewriting started

3.6 AOF 重写流程

┌─────────────────────────────────────────────────┐ │ AOF 重写流程（BGREWRITEAOF） │ ├─────────────────────────────────────────────────┤ │ │ │ 1. Redis 主进程 fork 子进程 │ │ ├─ 主进程：继续处理客户端请求 │ │ │ └─ 新命令写入：旧 AOF + 重写缓冲区 │ │ └─ 子进程：遍历内存，生成新 AOF │ │ │ │ 2. 子进程完成，通知主进程 │ │ │ │ 3. 主进程追加重写缓冲区到新 AOF │ │ │ │ 4. 原子性替换旧 AOF 文件 │ │ │ └─────────────────────────────────────────────────┘

3.7 AOF 优缺点

优点：

数据完整性高：最多丢失 1 秒数据（everysec）
可读性强：文本格式，可以手动编辑修复
实时性好：每条命令都记录

缺点：

文件大：记录所有命令，文件比 RDB 大
恢复慢：需要重新执行所有命令
性能影响：每秒同步磁盘，有一定开销

四、RDB vs AOF 对比

4.1 全面对比表

对比项	RDB	AOF
文件大小	小（压缩的二进制）	大（文本命令）
恢复速度	快（直接加载）	慢（重新执行命令）
数据完整性	差（可能丢失分钟级数据）	好（最多丢失 1 秒）
性能影响	小（fork 子进程）	中（每秒同步磁盘）
可读性	不可读（二进制）	可读（文本）
灾难恢复	好（文件小，易传输）	一般（文件大）
实时性	差（定期快照）	好（实时记录）
CPU 消耗	fork 时较高	重写时较高
磁盘 IO	低（不频繁）	高（每秒写入）

4.2 选型建议

┌────────────────────────────────────────────┐ │ RDB vs AOF 选型决策树 │ ├────────────────────────────────────────────┤ │ │ │ 能容忍几分钟数据丢失？ │ │ ├─ YES → RDB │ │ │ 场景：缓存、非核心数据 │ │ │ │ │ └─ NO → 数据非常重要？ │ │ ├─ YES → AOF（everysec） │ │ │ 场景：订单、用户数据、金融 │ │ │ │ │ └─ 追求极致安全？ │ │ └─ RDB + AOF 混合 │ │ 场景：核心业务数据 │ │ │ └────────────────────────────────────────────┘

推荐配置：

# 场景 1：纯缓存（可以重建）appendonly no# 关闭 AOFsave9001# 定期 RDB 即可save30010save6010000# 场景 2：重要数据（不能丢失）appendonlyyes# 开启 AOFappendfsync everysec# 每秒同步save""# 可关闭 RDB（或保留作为冷备份）# 场景 3：核心业务（最高安全）appendonlyyes# 开启 AOFappendfsync everysec save9001# 保留 RDB 作为冷备份aof-use-rdb-preambleyes# 混合持久化

五、混合持久化

5.1 什么是混合持久化

Redis 4.0+ 新特性：AOF 文件 = RDB 格式 + AOF 命令

传统 AOF 文件（纯命令）： ┌────────────────────────────────────┐ │ SET key1 value1 │ │ SET key2 value2 │ │ ... │ │ （1000 万条命令，文件很大） │ └────────────────────────────────────┘ 混合持久化 AOF 文件： ┌────────────────────────────────────┐ │ [RDB 格式数据] ← 快照数据（占 90%） │ │ （压缩的二进制，恢复快） │ ├────────────────────────────────────┤ │ SET key_new value_new ← 增量命令 │ │ INCR counter │ │ （快照后的新命令，占 10%） │ └────────────────────────────────────┘

5.2 配置混合持久化

# redis.conf# ========== 开启混合持久化 ==========aof-use-rdb-preambleyes# Redis 4.0+ 支持# ========== 同时开启 AOF ==========appendonlyyesappendfsync everysec# ========== RDB 配置（可选）==========save9001save30010save6010000

5.3 混合持久化流程

┌─────────────────────────────────────────────┐ │ 混合持久化工作流程 │ ├─────────────────────────────────────────────┤ │ │ │ 1. AOF 重写触发 │ │ └─ BGREWRITEAOF │ │ │ │ 2. 子进程生成 RDB 格式数据 │ │ └─ 写入新 AOF 文件开头 │ │ │ │ 3. 主进程继续收集新命令 │ │ └─ 写入重写缓冲区 │ │ │ │ 4. 子进程完成，主进程追加增量命令 │ │ └─ 以 AOF 格式追加到文件末尾 │ │ │ │ 5. 替换旧 AOF 文件 │ │ │ └─────────────────────────────────────────────┘

5.4 优势

恢复速度对比（100 万条数据）：

方式	恢复耗时	文件大小
纯 AOF	30 秒	200 MB
纯 RDB	2 秒	50 MB
混合持久化	5 秒	60 MB

优点：

恢复快：RDB 部分快速加载
数据完整：增量 AOF 补充最新数据
文件小：比纯 AOF 小很多

六、数据恢复流程

6.1 恢复优先级

Redis 启动时的恢复优先级： ┌─────────────────────────────────────┐ │ 1. 检查是否有 AOF 文件 │ │ ├─ 有 → 加载 AOF（优先） │ │ └─ 无 → 继续检查 │ │ │ │ 2. 检查是否有 RDB 文件 │ │ ├─ 有 → 加载 RDB │ │ └─ 无 → 空数据启动 │ │ │ └─────────────────────────────────────┘

为什么 AOF 优先？

AOF 数据更完整（实时记录）
RDB 可能丢失几分钟数据

6.2 手动恢复步骤

# 步骤 1：停止 Redis$ redis-clishutdown# 步骤 2：复制备份文件到数据目录$cp/backup/dump.rdb /var/lib/redis/ $cp/backup/appendonly.aof /var/lib/redis/# 步骤 3：修改文件权限$chownredis:redis /var/lib/redis/dump.rdb $chownredis:redis /var/lib/redis/appendonly.aof# 步骤 4：启动 Redis$ redis-server /etc/redis/redis.conf# 步骤 5：验证数据$ redis-cli127.0.0.1:6379>DBSIZE(integer)1000000# 数据已恢复 ✅

6.3 AOF 文件损坏修复

# 场景：AOF 文件损坏（断电、磁盘故障）# 1. 检查 AOF 文件$ redis-check-aof /var/lib/redis/appendonly.aof# AOF analyzed: size=12345678, ok_up_to=12340000, diff=5678# This will shrink the AOF from 12345678 bytes, with 5678 bytes, to 12340000 bytes# 2. 修复 AOF 文件（删除损坏部分）$ redis-check-aof--fix/var/lib/redis/appendonly.aof# Successfully truncated AOF# 3. 重启 Redis$ redis-server /etc/redis/redis.conf

6.4 RDB 文件损坏检查

# 检查 RDB 文件$ redis-check-rdb /var/lib/redis/dump.rdb# [offset 0] Checking RDB file dump.rdb# [offset 26] AUX FIELD redis-ver = '7.0.15'# ...# [offset 12345678] Checksum OK# RDB looks OK ✅# 如果损坏# RDB file is corrupted! ❌# 解决：使用备份 RDB 或 AOF 恢复

七、持久化最佳实践

7.1 生产环境推荐配置

# redis.conf# ========== 混合持久化（推荐）==========appendonlyyesaof-use-rdb-preambleyesappendfsync everysec# ========== RDB 作为冷备份 ==========save9001save30010save6010000dbfilename dump.rdb rdbcompressionyesrdbchecksumyes# ========== AOF 重写优化 ==========auto-aof-rewrite-percentage100auto-aof-rewrite-min-size 64mb# ========== 数据目录 ==========dir/var/lib/redis# ========== 错误处理 ==========stop-writes-on-bgsave-erroryes

7.2 备份策略

# 定时备份脚本（每天凌晨 2 点）#!/bin/bash# backup-redis.shBACKUP_DIR="/backup/redis/$(date+%Y%m%d)"REDIS_DIR="/var/lib/redis"# 创建备份目录mkdir-p$BACKUP_DIR# 触发 RDB 快照redis-cli BGSAVE# 等待 BGSAVE 完成while[$(redis-cli LASTSAVE)-eq$(redis-cli LASTSAVE)];dosleep1done# 复制 RDB 和 AOF 文件cp$REDIS_DIR/dump.rdb$BACKUP_DIR/cp$REDIS_DIR/appendonly.aof$BACKUP_DIR/# 压缩备份cd$BACKUP_DIRtar-czfredis_backup_$(date+%Y%m%d_%H%M%S).tar.gz *.rdb *.aofrm-f*.rdb *.aof# 删除 7 天前的备份find/backup/redis/-mtime+7-typed-execrm-rf{}\;echo"Redis backup completed:$BACKUP_DIR"

# 添加到 crontab$crontab-e02* * * /usr/local/bin/backup-redis.sh

7.3 性能优化建议

# 1. 使用 SSD 存储 AOF 文件dir/ssd/redis# 2. 调整 Linux 内核参数$sysctl-wvm.overcommit_memory=1# 允许内存超分配$echonever>/sys/kernel/mm/transparent_hugepage/enabled# 禁用大页# 3. 监控 fork 耗时127.0.0.1:6379>INFO stats# latest_fork_usec:12345 # 单位：微秒# 如果 fork 耗时 > 1 秒，考虑：# - 减少 Redis 内存使用# - 分拆实例# - 调整 save 触发条件

7.4 监控指标

# 关键监控指标127.0.0.1:6379>INFO persistence# rdb_changes_since_last_save:12345 # 上次 RDB 后修改次数# rdb_last_save_time:1735689600 # 上次 RDB 时间戳# rdb_last_bgsave_status:ok # 上次 RDB 状态# aof_enabled:1 # AOF 是否开启# aof_current_size:123456789 # 当前 AOF 大小# aof_base_size:100000000 # 上次重写后 AOF 大小# aof_last_rewrite_time_sec:12 # 上次重写耗时# aof_last_bgrewrite_status:ok # 上次重写状态

告警规则：

rdb_last_bgsave_status!= ok → RDB 失败
aof_last_bgrewrite_status!= ok → AOF 重写失败
latest_fork_usec> 1000000 → fork 耗时 > 1 秒
aof_current_size/aof_base_size> 2 → AOF 文件过大

八、常见问题排查

8.1 BGSAVE 失败

现象：

127.0.0.1:6379>BGSAVE(error)ERR Background save alreadyinprogress

原因：已经有 BGSAVE 在运行

解决：

# 查看进程$psaux|grepredis-rdb-bgsave# 等待完成，或 kill 进程（慎用）

现象：

127.0.0.1:6379>SET key value(error)MISCONF Redis is configured to save RDB snapshots, but it is currently not able to persist on disk.

原因：磁盘空间不足或权限问题

解决：

# 1. 检查磁盘空间$df-h# 清理空间# 2. 检查权限$ls-ld/var/lib/redis# drwxr-xr-x 2 redis redis# 3. 临时禁用保护（紧急）127.0.0.1:6379>CONFIG SET stop-writes-on-bgsave-error no

8.2 AOF 文件过大

现象：AOF 文件几十 GB

原因：未自动重写或重写频率低

解决：

# 1. 手动重写127.0.0.1:6379>BGREWRITEAOF# 2. 调整自动重写参数127.0.0.1:6379>CONFIG SET auto-aof-rewrite-percentage50127.0.0.1:6379>CONFIG SET auto-aof-rewrite-min-size 32mb# 3. 持久化配置127.0.0.1:6379>CONFIG REWRITE

8.3 恢复时间过长

现象：Redis 启动 10 分钟还没完成

原因：AOF 文件太大

解决：

# 1. 临时禁用 AOF，使用 RDB 恢复$vim/etc/redis/redis.conf appendonly no# 改为 no$ redis-server /etc/redis/redis.conf# 启动后再开启 AOF# 2. 使用混合持久化aof-use-rdb-preambleyes

九、常见面试题

9.1 基础概念题

Q1：Redis 持久化有哪几种方式？

答案：

RDB：快照持久化，定期生成内存快照
AOF：日志持久化，记录每条写命令
混合持久化：RDB + AOF（Redis 4.0+）

Q2：RDB 和 AOF 的区别？

对比项	RDB	AOF
文件大小	小	大
恢复速度	快	慢
数据完整性	差（可能丢失分钟级）	好（最多丢失1秒）
性能影响	小	中

Q3：AOF 的三种同步策略是什么？

答案：

always：每条命令同步，最安全，最慢
everysec：每秒同步，推荐，最多丢失1秒
no：操作系统决定，最快，最不安全

9.2 原理题

Q4：RDB 的 fork 过程是怎样的？

答案：

Redis 主进程执行fork()系统调用，创建子进程
子进程与主进程共享内存页（Copy-On-Write）
子进程遍历内存数据，写入 RDB 文件
主进程继续处理客户端请求
如果主进程修改数据，触发 COW，复制被修改的内存页
子进程完成后退出，主进程收到信号

关键：Copy-On-Write 保证子进程看到的是 fork 时刻的数据快照

Q5：AOF 重写是如何工作的？

答案：

Redis fork 子进程
子进程遍历内存，生成新 AOF 文件（只记录最终状态）
主进程继续处理请求，新命令写入：
- 旧 AOF 文件
- AOF 重写缓冲区
子进程完成，通知主进程
主进程将重写缓冲区内容追加到新 AOF
原子性替换旧 AOF 文件

Q6：什么是混合持久化？

答案：
Redis 4.0+ 新特性，AOF 文件 = RDB 格式数据 + AOF 增量命令

优点：

恢复速度快（RDB 部分快速加载）
数据完整（AOF 部分补充最新数据）
文件小（比纯 AOF 小很多）

配置：

aof-use-rdb-preambleyes

9.3 实战题

Q7：如何选择 RDB 还是 AOF？

答案：

选择 RDB：

可以容忍几分钟数据丢失
追求性能，减少磁盘 IO
场景：缓存、非核心数据

选择 AOF：

数据非常重要，不能丢失
需要高数据完整性
场景：订单、用户数据、金融

推荐配置：

RDB + AOF 混合：兼顾性能和安全
生产环境：开启混合持久化 + 定期备份

Q8：生产环境如何备份 Redis 数据？

答案：

自动备份：
- 定时任务（crontab）
- 执行 BGSAVE 生成 RDB
- 复制 RDB 和 AOF 到备份目录
- 压缩并上传到远程存储（OSS、S3）
备份频率：
- 全量备份：每天一次
- 增量备份：实时（AOF）
保留策略：
- 保留最近 7 天的全量备份
- 保留最近 1 个月的周备份
- 保留最近 1 年的月备份
恢复演练：
- 定期测试恢复流程
- 验证备份文件完整性

Q9：Redis 持久化会影响性能吗？

答案：

RDB 影响：

fork 子进程时短暂阻塞（毫秒级）
Copy-On-Write 可能导致内存短时翻倍
数据量大时，fork 可能耗时数秒

AOF 影响：

appendfsync everysec：每秒同步磁盘，性能影响 < 10%
appendfsync always：每次同步，性能下降 50%+
AOF 重写时 CPU 和磁盘 IO 增加

优化建议：

使用 SSD 存储
调整save触发条件，降低 RDB 频率
AOF 使用everysec模式
监控latest_fork_usec，优化 fork 耗时
避免业务高峰期手动触发 BGSAVE

Q10：如何防止 Redis 数据丢失？

答案：

持久化层面：

开启 AOF，使用appendfsync everysec
开启混合持久化
定期备份 RDB 和 AOF 文件到远程

架构层面：

使用主从复制（多副本）
使用哨兵或 Cluster（高可用）
异地容灾备份

监控层面：

监控持久化状态（rdb_last_bgsave_status、aof_last_bgrewrite_status）
监控磁盘空间
设置告警规则

应急预案：

定期恢复演练
保留多个备份版本
主从切换方案

🎉 总结

本文全面讲解了 Redis 持久化机制：

✅RDB：快照持久化、fork + COW、配置优化
✅AOF：日志持久化、三种同步策略、重写机制
✅混合持久化：RDB + AOF、恢复速度快
✅数据恢复：恢复优先级、文件修复
✅最佳实践：生产配置、备份策略、性能优化
✅问题排查：常见故障、解决方案
✅面试宝典：10 道高频面试题