Redis 持久化机制

Redis 提供三种持久化机制：RDB（快照）、AOF（追加文件）和混合持久化（Hybrid）。理解其原理是正确配置的前提。

RDB 快照原理

工作机制

RDB 通过 fork 子进程生成内存数据的二进制快照。

Redis 主进程 → fork → 子进程（共享内存-Cow）
                       └── 读取内存数据写入临时 RDB 文件
                       └── 完成后替换旧 RDB 文件
父进程继续处理请求（Copy-On-Write 机制）

• fork 产生的阻塞时间通常 < 几百毫秒
• 生成紧凑的二进制文件，便于备份和传输
• 恢复大数据集比 AOF 快

触发方式

关键配置

dbfilename dump.rdb
dir /var/lib/redis
save 900 1            # 900 秒内 1 次写操作
save 300 100          # 300 秒内 100 次写操作
save 60 10000         # 60 秒内 10000 次写操作
stop-writes-on-bgsave-error yes   # 备份失败时停止写入（建议开启）
rdbcompression yes                 # LZF 压缩
rdbchecksum yes                    # CRC64 校验

优缺点

优点： 文件小、恢复快、便于传输备份 缺点： 可能丢失两次快照之间的数据、fork 大内存时有性能冲击

AOF 追加文件原理

工作机制

AOF 记录所有写命令，重启时逐条执行恢复数据。

写命令 → 追加到 AOF 缓冲区 → 根据 fsync 策略同步到磁盘

fsync 三种策略

生产建议： 多数场景用 everysec；严格场景用 always。

AOF 重写

AOF 文件持续增长 → 需要重写（Rewrite）压缩命令序列。

# 手动触发
redis-cli BGREWRITEAOF

# 自动触发配置
auto-aof-rewrite-percentage 100    # 增长 100% 时触发
auto-aof-rewrite-min-size 64mb     # 最小触发大小

重写由后台子进程完成，不阻塞主进程。

关键配置

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
aof-load-truncated yes          # 截断的 AOF 文件是否加载
aof-use-rdb-preamble yes        # 混合持久化（Redis 4.0+）

混合持久化（Redis 4.0+）

结合 RDB 和 AOF 的优点，在 AOF 重写时用 RDB 格式写入数据开头，后续命令以 AOF 格式追加。

[AOF 重写后的文件]
┌──────────────────────────────┐
│  RDB 格式（数据快照）         │ ← 快速恢复
├──────────────────────────────┤
│  AOF 格式（增量写命令）        │ ← 增量能力
└──────────────────────────────┘

• 恢复速度比纯 AOF 快
• 文件比纯 AOF 小
• 保留增量同步能力
• 缺点： 不再是纯文本格式

数据丢失场景分析

业务场景选择建议

状态监控

# 查看持久化状态
redis-cli INFO persistence

# 关键指标
rdb_changes_since_last_save    # 距上次 RDB 的变更数
rdb_last_bgsave_status          # 上次 BGSAVE 状态 (ok/err)
rdb_last_save_time              # 上次保存时间戳
aof_current_size                # 当前 AOF 文件大小
aof_last_rewrite_status         # 上次重写状态
aof_last_write_status           # 上次写入状态

关联页面