关于Redis持久化

一、为什么持久化是Redis的命脉？

Redis作为内存数据库，所有数据存储在RAM中，进程退出或服务器宕机将导致数据丢失。持久化机制通过将内存数据落盘解决此问题，实现：

• 故障恢复：重启后快速重建数据集

• 数据备份：支持跨机房/跨区域容灾

• 版本回滚：误操作后可通过历史快照恢复

• 数据安全：避免突发故障导致全量数据丢失 26

---

二、RDB持久化：快照式备份

▶ 核心原理

在指定时间点生成数据集二进制快照（Snapshot），保存为dump.rdb文件。触发方式包括：

• 自动触发：按配置规则执行（如save 60 10000）

• 手动触发：SAVE（阻塞主线程）或BGSAVE（后台异步）23

▶ 工作流程

主进程接收BGSAVE请求

fork子进程

子进程写数据到临时RDB文件

写入完成替换旧RDB

发送信号通知主进程

写时复制（Copy-on-Write）：
子进程与父进程共享内存页，仅当父进程修改数据时复制对应内存页，极大减少内存占用 9。

▶ 配置优化

# redis.conf关键参数
save 900 1       # 15分钟内1次修改即触发
save 300 10      # 5分钟内10次修改
rdbcompression yes # LZF压缩减少50%+体积
rdbchecksum yes   # 校验和防数据损坏
stop-writes-on-bgsave-error yes # 持久化失败拒写

▶ 优劣势分析

优势	劣势
文件紧凑（二进制压缩）	可能丢失最后一次快照后的数据
恢复速度极快（直接载入内存）	大数据集fork可能阻塞主进程
最大化Redis性能（后台执行）	实时性差（分钟级备份）36

---

三、AOF持久化：操作日志追迹

▶ 核心原理

记录所有写操作命令（文本格式），通过重放日志恢复数据。写入流程：
写命令 → AOF缓冲区 → 同步策略 → 磁盘AOF文件

▶ 同步策略权衡

appendfsync	数据安全性	性能影响
always	最高（0丢失）	极差（每次写同步磁盘）
everysec	中等（丢1秒数据）	平衡（推荐生产环境）
no	低（依赖OS刷盘）	最高 27

▶ AOF重写：解决日志膨胀

触发条件：

• 文件大小超过auto-aof-rewrite-min-size

• 增长比例达auto-aof-rewrite-percentage

重写过程：

1. fork子进程扫描内存生成最小命令集

2. 期间新命令写入AOF重写缓冲区

3. 重写完成后追加缓冲区内容到新AOF

4. 原子替换旧文件 19

优化配置：

auto-aof-rewrite-percentage 100 # 文件增长100%触发
auto-aof-rewrite-min-size 64mb  # 最小文件大小
no-appendfsync-on-rewrite yes   # 重写期间不fsync（提升性能）

▶ 优劣势对比

优势	劣势
数据完整性高（秒级同步）	文件体积通常大于RDB
可读性强（文本命令日志）	恢复速度慢（需重放命令）
支持误操作修复（删除错误命令）	开启后QPS下降约10-15% 68

---

四、混合持久化（Redis 4.0+）：鱼与熊掌兼得

▶ 核心机制

[RDB二进制数据] + [增量AOF命令]

• 写入流程：

  1. AOF重写时先以RDB格式保存全量数据

  2. 后续增量命令以AOF格式追加 58

▶ 配置启用

aof-use-rdb-preamble yes  # 开启混合模式

• 恢复速度：比纯AOF提升3倍+（优先加载RDB快照）

• 数据完整性：AOF补全RDB后的增量数据

• 空间效率：比纯AOF节省30%+空间 57