Redis 持久化深入

SunnyFan大约 17 分钟约 5002 字

Redis 持久化深入

简介

Redis 持久化机制决定了内存中的数据在重启后能否恢复。Redis 提供两种持久化方式：RDB（快照）和 AOF（追加日志），以及 4.0 起支持的混合持久化。理解它们的原理、触发时机和恢复流程，是保证 Redis 数据安全和制定备份策略的基础。

为什么 Redis 需要持久化

Redis 是内存数据库，数据存储在内存中。如果没有持久化，Redis 进程退出或服务器重启后，所有数据将丢失。但并非所有场景都需要持久化：

纯缓存场景：Redis 只是 MySQL 的缓存，数据可以随时从数据库重建，不需要持久化
数据存储场景：Redis 作为主存储（如会话管理、排行榜、消息队列），数据丢失不可接受，必须持久化
混合场景：部分数据需要持久化，部分不需要（通过 SELECT 选择性持久化）

RDB 快照机制

RDB 工作原理

RDB 通过 fork() 创建子进程，子进程将内存数据以二进制形式写入临时文件，写入完成后替换旧的 RDB 文件。这个过程利用了操作系统的 Copy-On-Write（写时复制）机制。

RDB 快照流程：

Redis 主进程                子进程
    |                          |
    |--- fork() -------------->|
    |                          |--- 遍历内存，写入 RDB 文件
    |                          |    （读取时不修改内存）
    |--- 继续处理客户端请求      |
    |    写操作触发 COW         |
    |    （被修改的页会被复制）   |
    |                          |--- 写入完成
    |<-- 通知主进程 ------------|
    |--- 替换旧 RDB 文件        |

Copy-On-Write（COW）详解：
- fork() 时，子进程与父进程共享相同的物理内存页
- 父进程的写操作会触发 COW：被修改的内存页会被复制一份
- 子进程继续读取原始页（不受父进程写入影响）
- 因此 fork() 的内存开销取决于 fork 后的写操作量

RDB 配置

# redis.conf 中配置自动 RDB 快照条件
save 900 1        # 900秒（15分钟）内至少1次修改就触发
save 300 10       # 300秒（5分钟）内至少10次修改
save 60 10000     # 60秒（1分钟）内至少10000次修改

# 三个条件满足任意一个就触发快照
# 如果都不想触发，设为 save ""（禁用自动快照）

# Redis 7.0+ 使用新的配置方式（统一格式）
save 3600 1 300 100 60 10000

# 手动触发 RDB 快照
BGSAVE           # 后台异步保存（fork 子进程，不阻塞主线程）
SAVE             # 同步保存（阻塞主线程直到完成，生产环境慎用）

# 查看最近一次 RDB 信息
LASTSAVE         # 返回最近一次成功保存的 UNIX 时间戳

# RDB 文件配置
dbfilename dump.rdb                    # RDB 文件名
dir /var/lib/redis                     # RDB 文件目录
rdbcompression yes                     # 是否压缩（LZF 压缩）
rdbchecksum yes                        # 是否校验和

# 查看持久化状态
INFO persistence
# rdb_last_save_time: 1710000000        # 最近保存时间
# rdb_changes_since_last_save: 1234     # 自上次保存后的修改次数
# rdb_bgsave_in_progress: 0             # 是否正在进行 BGSAVE
# rdb_last_bgsave_status: ok            # 最近 BGSAVE 是否成功
# rdb_last_bgsave_time_sec: 2           # 最近 BGSAVE 耗时（秒）
# rdb_last_cow_size: 1048576            # 最近 COW 复制大小（字节）

RDB 恢复流程

# RDB 恢复步骤
# 1. 停止 Redis
redis-cli SHUTDOWN NOSAVE

# 2. 将 RDB 文件放入 Redis 数据目录
cp /backup/dump_20240115.rdb /var/lib/redis/dump.rdb

# 3. 启动 Redis（自动加载 dump.rdb）
redis-server /etc/redis/redis.conf

# RDB 恢复特点：
# - 恢复速度极快（直接加载二进制文件到内存）
# - GB 级数据几秒到几十秒恢复
# - 恢复后数据是快照时刻的状态，快照后的修改会丢失

AOF 追加日志机制

AOF 工作原理

AOF（Append Only File）将 Redis 的每条写命令以 Redis 协议格式追加到日志文件末尾。恢复时重新执行日志中的所有命令来重建数据。

AOF 工作流程：

客户端写命令
    ↓
追加到 AOF 缓冲区（aof_buf）
    ↓
根据 appendfsync 策略写入 AOF 文件
    ↓
AOF 文件持续增长
    ↓
触发 AOF 重写（BGREWRITEAOF）
    ↓
生成压缩后的新 AOF 文件

AOF 文件内容示例：
*3          # 命令有 3 个参数
$3          # 第一个参数长度 3
SET         # 命令名
$5          # 第二个参数长度 5
mykey       # 键名
$5          # 第三个参数长度 5
hello       # 值

AOF 配置

# 开启 AOF
appendonly yes

# AOF 文件名
appendfilename "appendonly.aof"

# AOF 刷盘策略（关键参数）
# always    : 每条命令都 fsync，最安全但最慢（约 200-400 TPS）
# everysec  : 每秒 fsync 一次（推荐），最多丢 1 秒数据
# no        : 由操作系统决定何时刷盘，最快但最不安全（可能丢很多数据）
appendfsync everysec

# AOF 重写触发条件
auto-aof-rewrite-percentage 100   # AOF 文件大小比上次重写后增长 100%
auto-aof-rewrite-min-size 64mb    # AOF 文件最小 64MB 才触发重写

# 手动触发 AOF 重写
BGREWRITEAOF

# AOF 重写原理（与 RDB 类似）：
# 1. fork() 创建子进程
# 2. 子进程读取当前内存数据，生成最小化的 AOF 命令序列
# 3. 父进程在此期间的新写命令同时追加到 AOF 重写缓冲区和旧 AOF 文件
# 4. 子进程完成后，将重写缓冲区的内容追加到新 AOF 文件
# 5. 原子替换旧 AOF 文件

# AOF 损坏修复
redis-check-aof --fix appendonly.aof
# 会扫描文件，截断到最近一条完整命令的位置
# 修复前建议备份原文件

混合持久化（推荐方案）

Redis 4.0 引入混合持久化，结合了 RDB 的恢复速度和 AOF 的数据安全性。

混合持久化 AOF 文件结构：

[RDB 格式数据（二进制快照）]  ← 恢复时直接加载，速度快
[AOF 增量命令（Redis 协议）] ← 恢复时逐条执行，保证精确性

恢复流程：
1. 先加载 RDB 部分（快速恢复大部分数据）
2. 再重放 AOF 增量部分（恢复快照后的修改）

优势：
- 恢复速度比纯 AOF 快 5-10 倍
- 数据安全性接近纯 AOF（只丢失重写期间的数据）

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

# 查看当前 AOF 文件信息
INFO persistence
# aof_current_size: 10485760        # 当前 AOF 文件大小
# aof_base_size: 5242880            # 上次重写后的 AOF 大小
# aof_pending_rewrite: 0            # 是否等待重写
# aof_buffer_length: 0              # AOF 缓冲区大小
# aof_rewrite_buffer_length: 0      # AOF 重写缓冲区大小

# 从混合持久化 AOF 文件恢复数据
# 1. 停止 Redis
# 2. 将 appendonly.aof 放入 Redis 数据目录
# 3. 启动 Redis（自动加载 AOF）
# Redis 会自动检测文件格式，RDB 头部用 RDB 方式加载，尾部用 AOF 方式重放

Redis 7.0 Multi Part AOF

Redis 7.0 对 AOF 做了重大改进，引入了 Multi Part AOF 机制：

Redis 7.0 Multi Part AOF 结构：

MANIFEST 文件（记录 AOF 文件列表和状态）
    |
    ├── BASE 文件（RDB 格式，初始快照）
    ├── INCR.1 文件（AOF 格式，增量 1）
    ├── INCR.2 文件（AOF 格式，增量 2）
    └── ...

优势：
1. AOF 重写不再需要 fork 全量内存
2. 只需要将 INCR 文件合并到新的 INCR 文件
3. 减少重写期间的内存压力
4. 支持更细粒度的 AOF 管理

持久化性能影响

fork() 的开销

fork() 是 RDB 和 AOF 重写的共同基础，其开销取决于 Redis 实例的内存大小：

fork() 耗时参考（经验值）：

Redis 内存    fork() 耗时
1 GB          约 10-20 ms
5 GB          约 50-100 ms
10 GB         约 100-200 ms
20 GB         约 200-500 ms
50 GB         约 1-2 秒

影响 fork() 耗时的因素：
- Redis 实例使用的内存大小
- fork() 时的内存碎片率
- 操作系统的 overcommit 设置
- 是否开启了 Transparent Huge Pages（THP）

# 监控 fork 耗时
INFO persistence
# rdb_last_bgsave_time_sec: 2.35     # 最近 BGSAVE 耗时
# latest_fork_usec: 152000           # 最近 fork 耗时（微秒）

# fork 耗时超过 1000ms 告警
redis-cli INFO persistence | grep latest_fork_usec
# latest_fork_usec:1500000  → 1.5 秒，已超过 1 秒阈值

# 优化 fork 耗时
# 1. 关闭 Transparent Huge Pages
echo never > /sys/kernel/mm/transparent_hugepage/enabled

# 2. 控制 Redis 实例内存大小（建议单实例不超过 10GB）

# 3. 降低内存碎片率
#    使用 activedefrag yes（Redis 4.0+）
activedefrag yes

Copy-On-Write 内存开销

fork() 后，父进程的写操作会触发 COW，导致物理内存增长：

# 监控 COW 开销
INFO persistence
# rdb_last_cow_size: 20971520    # 最近 BGSAVE 的 COW 大小（20MB）
# aof_last_cow_size: 10485760    # 最近 AOF 重写的 COW 大小（10MB）

# COW 风险评估
# 如果 fork() 后写入量很大，COW 可能导致物理内存接近翻倍
# 极端情况下可能触发 OOM（Out of Memory）

# 监控 Redis 内存
INFO memory
# used_memory: 4294967296         # Redis 使用的内存（4GB）
# used_memory_rss: 5368709120     # 操作系统分配的内存（5GB）
# mem_fragmentation_ratio: 1.25   # 碎片率（RSS / used_memory）
# 如果 RSS 远大于 used_memory，说明碎片严重或 COW 开销大

持久化监控与故障恢复

#!/bin/bash
# Redis 持久化健康检查脚本

REDIS_CLI="redis-cli -h 127.0.0.1 -p 6379"

# 1. 检查 RDB 状态
RDB_LAST_SAVE=$($REDIS_CLI LASTSAVE)
RDB_CHANGES=$($REDIS_CLI INFO persistence | grep rdb_changes_since_last_save)
echo "Last RDB save: $RDB_LAST_SAVE"
echo "$RDB_CHANGES"

# 2. 检查 AOF 状态
AOF_ENABLED=$($REDIS_CLI CONFIG GET appendonly | tail -1)
AOF_SIZE=$($REDIS_CLI INFO persistence | grep aof_current_size)
echo "AOF enabled: $AOF_ENABLED"
echo "$AOF_SIZE"

# 3. 检查最近 fork 状态
FORK_USEC=$($REDIS_CLI INFO persistence | grep latest_fork_usec)
echo "$FORK_USEC"

# 4. 检查 COW 开销
COW_SIZE=$($REDIS_CLI INFO persistence | grep rdb_last_cow_size)
echo "$COW_SIZE"

# 5. 检查 AOF 重写状态
BGREWRITE=$($REDIS_CLI INFO persistence | grep aof_last_bgrewrite_status)
echo "$BGREWRITE"

# 6. 备份 RDB 文件到远程存储
BACKUP_DIR="/backup/redis/$(date +%Y%m%d)"
mkdir -p $BACKUP_DIR
cp /var/lib/redis/dump.rdb $BACKUP_DIR/dump_$(date +%Y%m%d%H%M).rdb

# 7. 上传到远程存储（S3/OSS）
# aws s3 cp $BACKUP_DIR/dump_*.rdb s3://my-bucket/redis-backup/

echo "Backup completed: $BACKUP_DIR"

持久化方案选型

持久化方案详细对比

RDB vs AOF 详细对比：
| 维度           | RDB                          | AOF                          |
|---------------|------------------------------|------------------------------|
| 持久化方式      | 快照（时间点数据）              | 追加日志（每条写命令）          |
| 数据安全性      | 可能丢失两次快照间的所有写入      | everysec 最多丢 1 秒          |
| 恢复速度       | 极快（直接加载二进制）           | 较慢（逐条重放命令）            |
| 文件大小       | 紧凑（二进制压缩）              | 较大（文本格式命令）            |
| 对性能影响      | fork 瞬间 + COW 开销          | 每秒 fsync + 重写时 COW 开销    |
| 适用场景       | 备份、灾难恢复、跨环境迁移       | 数据安全要求高的在线服务        |

混合持久化对比：
| 维度           | 纯 AOF          | 混合持久化（RDB+AOF）        |
|---------------|-----------------|----------------------------|
| 恢复速度       | 慢               | 快（5-10 倍提升）           |
| 文件大小       | 大               | 较小                       |
| 数据安全性      | 高               | 高                         |
| 兼容性         | 所有版本          | Redis 4.0+                |

不同业务场景的持久化配置模板

# 场景1：纯缓存（推荐关闭持久化）
save ""
appendonly no
# 理由：数据全部可从数据库重建，关闭持久化提升性能和延长磁盘寿命

# 场景2：会话管理（混合持久化）
save 900 1 300 10 60 10000
appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes
# 理由：会话数据丢失影响用户体验，需要快速恢复

# 场景3：消息队列（纯 AOF，高安全）
appendonly yes
appendfsync everysec
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 理由：消息丢失不可接受，AOF 保证最细粒度的数据安全

# 场景4：排行榜/计数器（混合持久化 + 高频快照）
save 900 1 300 10 60 1000
appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes
# 理由：排行榜重建代价大，但短暂丢失可接受

# 场景5：大内存实例（> 10GB，优化 fork 开销）
save 3600 1 300 100 60 10000
appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes
# 降低 RDB 快照频率，减少 fork 次数
# 建议：大实例使用多小实例替代单大实例

RDB 文件深入分析

RDB 文件格式

RDB 文件内部结构：
+----------+--------+----------+--------+-----+-------+
| REDIS    | DB     | KEY-VAL  | KEY-VAL| ... | EOF   |
| 版本号   | 选择器  | 对数据    | 对数据  |     | 校验和 |
+----------+--------+----------+--------+-----+-------+

详细结构：
1. Magic String: "REDIS" + 版本号（如 0012）
2. Database Selector: SELECTDB + 数据库编号
3. Key-Value Pairs:
   - 过期时间（可选）：EXPIRETIME_MS + 毫秒时间戳
   - 类型标识：string/list/set/zset/hash/stream 等
   - Key: 编码后的键名
   - Value: 编码后的值（可能经过 LZF 压缩）
4. EOF: 结束标记
5. CRC64 校验和

压缩编码：
- 整数：小整数用变长编码（1-9 字节）
- 字符串：短字符串不压缩，长字符串使用 LZF 压缩
- 集合/列表：ziplist/intset 等紧凑编码直接写入

RDB 文件操作与验证

# 查看 RDB 文件信息
redis-check-rdb /var/lib/redis/dump.rdb
# 输出文件结构、键数量、编码方式等

# 检查 RDB 文件完整性（不修复）
redis-check-rdb /var/lib/redis/dump.rdb
# [offset 0] Checking RDB file dump.rdb
# [offset 26] AUX FIELD redis-ver = '7.2.3'
# [offset 1337] Selecting DB ID 0
# [offset 2468] Checksum OK

# 解析 RDB 文件内容（使用 rdb-tools）
pip install rdb-tools
rdb --command json /var/lib/redis/dump.rdb > dump.json
rdb --command justkeys /var/lib/redis/dump.rdb | head -20

# 生成 RDB 文件的内存分析报告
rdb -c memory /var/lib/redis/dump.rdb > memory_report.csv
# 输出：key、内存占用、编码方式、过期时间等

# 按 Key 前缀过滤
rdb --command json -k "session:*" /var/lib/redis/dump.rdb

AOF 重写深入

AOF 重写流程详解

AOF 重写完整流程：

时间线：
T1: 主进程收到 BGREWRITEAOF 命令（自动或手动触发）
T2: fork() 创建子进程
    - 主进程继续处理客户端请求
    - 新的写命令同时追加到：
      a) AOF 缓冲区（aof_buf）
      b) AOF 重写缓冲区（aof_rewrite_buf）

T3: 子进程读取当前内存，生成最小化命令序列
    - 例如：SET key1 a; SET key1 b; SET key1 c → SET key1 c
    - 例如：SADD myset a; SADD myset b; SADD myset a → SADD myset a b
    - 例如：RPUSH mylist a; LPOP mylist; RPUSH mylist b → RPUSH mylist b

T4: 子进程完成重写，通知主进程
T5: 主进程将 AOF 重写缓冲区的内容追加到新 AOF 文件
T6: 原子替换旧 AOF 文件（rename 系统调用）

注意：T5 步骤如果重写缓冲区太大，可能导致短暂阻塞

AOF 重写优化策略

# 调整重写触发条件
# 默认：AOF 文件比上次重写后增长 100% 且超过 64MB
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 高写入场景（AOF 增长快）
# 降低触发阈值，更频繁地重写
auto-aof-rewrite-percentage 50
auto-aof-rewrite-min-size 128mb

# 低写入场景
# 提高触发阈值，减少不必要的重写
auto-aof-rewrite-percentage 200
auto-aof-rewrite-min-size 256mb

# 查看重写缓冲区大小
INFO persistence | grep aof_rewrite_buffer_length
# 如果重写缓冲区很大（> 100MB），说明 fork 期间写入量大
# 解决方案：控制实例内存、降低写入频率、错峰重写

# 避免重写叠加
# 如果正在 BGSAVE，BGREWRITEAOF 会被自动推迟
# 如果正在 BGREWRITEAOF，新的 BGREWRITEAOF 会被拒绝
# 可以通过 INFO persistence 的 aof_rewrite_in_progress 查看

生产环境持久化最佳实践

持久化监控指标

# 关键监控指标和告警阈值
# 1. fork 耗时
# 告警阈值: > 1000ms（1 秒）
redis-cli INFO persistence | grep latest_fork_usec

# 2. RDB 快照状态
# 告警条件: rdb_last_bgsave_status != ok
redis-cli INFO persistence | grep rdb_last_bgsave_status

# 3. COW 内存开销
# 告警阈值: cow_size > used_memory * 50%
redis-cli INFO persistence | grep rdb_last_cow_size

# 4. AOF 重写状态
# 告警条件: aof_last_bgrewrite_status != ok
redis-cli INFO persistence | grep aof_last_bgrewrite_status

# 5. AOF 文件增长速度
# 告警阈值: 1 小时增长超过 1GB
redis-cli INFO persistence | grep aof_current_size

# 6. 持久化延迟
# 告警条件: rdb_last_bgsave_time_sec > 10
redis-cli INFO persistence | grep rdb_last_bgsave_time_sec

备份恢复自动化脚本

#!/bin/bash
# redis-backup.sh - Redis 持久化备份脚本
set -euo pipefail

REDIS_CLI="redis-cli -h ${REDIS_HOST:-127.0.0.1} -p ${REDIS_PORT:-6379}"
BACKUP_DIR="/backup/redis/$(date +%Y%m%d)"
RETENTION_DAYS=7

mkdir -p "$BACKUP_DIR"

# 1. 触发 BGSAVE（确保 RDB 文件是最新的）
echo "触发 BGSAVE..."
$REDIS_CLI BGSAVE

# 等待 BGSAVE 完成
while true; do
    status=$($REDIS_CLI LASTSAVE)
    sleep 1
    new_status=$($REDIS_CLI LASTSAVE)
    if [ "$status" != "$new_status" ]; then
        echo "BGSAVE 完成"
        break
    fi
    echo "等待 BGSAVE 完成..."
done

# 2. 获取 Redis 数据目录
REDIS_DIR=$($REDIS_CLI CONFIG GET dir | tail -1)
RDB_FILE=$($REDIS_CLI CONFIG GET dbfilename | tail -1)

# 3. 复制 RDB 文件
echo "备份 RDB 文件..."
cp "${REDIS_DIR}/${RDB_FILE}" "${BACKUP_DIR}/dump_$(date +%Y%m%d%H%M).rdb"

# 4. 备份 AOF 文件（如果开启）
AOF_ENABLED=$($REDIS_CLI CONFIG GET appendonly | tail -1)
if [ "$AOF_ENABLED" = "yes" ]; then
    AOF_FILE=$($REDIS_CLI CONFIG GET appendfilename | tail -1)
    echo "备份 AOF 文件..."
    cp "${REDIS_DIR}/${AOF_FILE}" "${BACKUP_DIR}/" 2>/dev/null || true
fi

# 5. 压缩备份
echo "压缩备份文件..."
tar czf "${BACKUP_DIR}.tar.gz" "$BACKUP_DIR"
rm -rf "$BACKUP_DIR"

# 6. 清理旧备份
find /backup/redis -name "*.tar.gz" -mtime +$RETENTION_DAYS -delete
echo "备份完成: ${BACKUP_DIR}.tar.gz"

Redis 持久化与主从复制

持久化与复制的交互：
1. 从节点默认不开启持久化（节省磁盘 I/O）
2. 从节点通过全量同步获取 RDB 文件（主节点 BGSAVE 生成）
3. 如果从节点开启持久化，全量同步时会先清空旧数据再写入新 RDB
4. 主从切换时，新主节点必须开启持久化（否则重启数据全丢）

推荐配置：
- 主节点：开启混合持久化（RDB + AOF）
- 从节点：可选择关闭持久化（通过复制保证数据安全）
- Sentinel 切换后：检查新主节点持久化配置
- 集群模式：每个主节点都需要开启持久化

常见问题：
- 从节点磁盘满导致 RDB 全量同步失败
- 主节点未开启持久化，Sentinel 切换后新主重启数据全丢
- 网络抖动导致频繁全量同步，磁盘 I/O 压力大

持久化方案选型

场景	推荐方案	原因
纯缓存	关闭持久化	数据可从数据库重建，关闭持久化提升性能
会话管理	混合持久化	数据量适中，需要快速恢复
排行榜/计数器	混合持久化	数据可重建但重建代价大
消息队列	AOF + everysec	不能丢失消息
数据分析	RDB 定时备份	数据量大，恢复速度重要