Redis持久化机制实战：RDB快照与AOF日志配置及混合持久化方案

Redis持久化是数据可靠性保障的基础。RDB快照以二进制文件保存内存状态，AOF日志记录每条写命令，混合持久化结合两者优势。理解各方案的原理与配置参数，根据业务场景选择合适的持久化策略，是Redis缓存策略落地的核心环节。

RDB快照机制与配置参数

RDB通过fork子进程将内存数据序列化到磁盘文件dump.rdb。触发方式包括：配置save规则自动触发、BGSAVE命令手动触发、主从复制时触发。fork采用Copy-On-Write技术，子进程写RDB期间主进程继续处理请求。

redis.conf中RDB配置：

# 自动快照规则：满足任意条件即触发
save 3600 1     # 1小时内至少1次修改
save 300 100    # 5分钟内至少100次修改
save 60 10000   # 1分钟内至少10000次修改

# 如果持久化出错，停止写入
stop-writes-on-bgsave-error yes

# RDB文件压缩，节省空间但增加CPU开销
rdbcompression yes

# RDB文件校验和
rdbchecksum yes

# RDB文件名
dbfilename dump.rdb

# 文件存储路径
dir /data/redis/

# fork时如果内存占用过大，可能触发系统OOM
# 通过 maxmemory 配置上限防失控
maxmemory 8gb
maxmemory-policy allkeys-lru

RDB的优点：文件紧凑、恢复速度快、适合备份和灾备。缺点：两次快照之间存在数据丢失窗口、fork大内存实例时可能导致主进程短暂卡顿。

AOF日志机制与重写优化

AOF以追加方式记录每条写命令，数据安全性高于RDB。AOF有三种fsync策略：always每次写命令都刷盘（最安全但性能最差）、everysec每秒刷盘（推荐，最多丢失1秒数据）、no由操作系统决定（性能最好但数据丢失风险最大）。

# 开启AOF
appendonly yes

# AOF文件名
appendfilename "appendonly.aof"

# fsync策略
appendfsync everysec

# AOF重写期间不执行fsync，避免磁盘IO竞争
no-appendfsync-on-rewrite yes

# AOF重写触发条件：文件大小比上次重写后增长100%
auto-aof-rewrite-percentage 100

# AOF重写触发条件：文件最小体积64MB
auto-aof-rewrite-min-size 64mb

# AOF文件目录，可与RDB分盘存放
dir /data/redis/

AOF重写机制：当AOF文件过大时，Redis fork子进程读取当前内存状态，生成最简命令集（例如对同一key的多次SET只保留最终值），重写完成后用新文件替换旧文件。重写期间新写命令同时写入旧AOF和重写缓冲区，完成后追加到新文件。

混合持久化方案配置

Redis 4.0引入混合持久化，AOF重写时不再写纯命令日志，而是先写RDB格式的全量数据快照，再追加增量AOF命令。恢复时先加载RDB部分（速度快），再回放AOF命令（补全增量数据），兼顾恢复速度和数据完整性。

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

# AOF重写时优先使用RDB前导
# 重写流程：
# 1. fork子进程
# 2. 子进程将内存数据写为RDB格式到新AOF文件
# 3. 父进程将重写期间的增量命令写入AOF重写缓冲区
# 4. 子进程完成后，父进程将缓冲区命令追加到新AOF文件
# 5. 原子替换旧AOF文件

# 验证AOF文件格式
# 头部为REDIS开头表示RDB格式，*开头表示纯AOF命令
head -c 20 /data/redis/appendonly.aof | xxd

持久化性能调优与监控

fork操作是持久化的性能瓶颈。大内存实例fork时复制页表耗时长，可通过info persistence监控fork指标：

127.0.0.1:6379> info persistence
# Persistence
loading:0
rdb_changes_since_last_save:1532
rdb_bgsave_in_progress:0
rdb_last_save_time:1725340800
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:12
rdb_current_bgsave_time_sec:-1

aof_enabled:1
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:8
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok

# 关键监控指标：
# latest_fork_usec: 最近一次fork耗时（微秒）
latest_fork_usec:153200

fork耗时超过100ms时考虑以下优化：

# 1. 控制单实例内存大小，建议不超过10GB
maxmemory 8gb

# 2. 使用透明大页（THP）时fork更快，但可能影响Copy-On-Write效率
echo never > /sys/kernel/mm/transparent_hugepage/enabled

# 3. 调整内核参数，降低fork延迟
# /etc/sysctl.d/99-redis.conf
vm.overcommit_memory=1
net.core.somaxconn=1024

# 4. 磁盘IO优化，RDB和AOF分磁盘
# RDB存SSD，AOF存NVMe
dir /data/redis/rdb/
appendfilename "/data/redis/aof/appendonly.aof"

数据恢复与灾备方案

# 从RDB文件恢复
# 1. 停止Redis
redis-cli shutdown nosave

# 2. 将dump.rdb放到dir配置的目录
cp /backup/dump-20260903.rdb /data/redis/dump.rdb

# 3. 启动Redis，自动加载RDB
redis-server /etc/redis/redis.conf

# 从AOF文件恢复
# 如果AOF文件损坏，使用redis-check-aof修复
redis-check-aof --fix /data/redis/appendonly.aof

# 混合持久化文件恢复
# Redis自动检测RDB前导，先加载RDB再回放AOF命令

# 定时备份脚本（crontab）
# 每小时备份RDB，每天备份AOF
0 * * * * cp /data/redis/dump.rdb /backup/redis/dump-$(date +%Y%m%d%H).rdb
0 2 * * * cp /data/redis/appendonly.aof /backup/redis/aof-$(date +%Y%m%d).aof

生产环境选型建议：纯缓存场景可关闭持久化或仅用RDB；对数据完整性要求高的场景使用混合持久化（AOF + RDB preamble）配合everysec fsync；大内存实例建议分片部署，单实例控制在8GB以内降低fork延迟。定期验证备份文件的完整性，确保灾备可恢复。