4. Redis 持久化机制：RDB 与 AOF 原理、混合持久化、数据恢复策略
Redis 作为内存数据库，其高性能依赖于数据常驻内存。但一旦进程退出或机器宕机，内存数据将全部丢失。持久化机制是 Redis 提供数据安全保障的核心能力，也是构建高可用缓存系统的基础。本章深入剖析 RDB、AOF 及混合持久化的原理、配置与恢复策略。
4.1 RDB 持久化：全量快照
RDB（Redis Database）通过创建内存数据的二进制快照文件（dump.rdb）实现持久化。它采用 Copy-On-Write（写时复制） 机制，由主进程 fork 出一个子进程专门负责快照写入，主进程继续处理客户端请求，两者互不阻塞。
4.1.1 触发方式
| 触发类型 | 命令/配置 | 说明 |
|---|---|---|
| 手动保存 | SAVE |
同步阻塞，主进程直接生成 RDB 文件，期间不处理任何请求 |
| 后台保存 | BGSAVE |
异步非阻塞，fork 子进程执行快照，主进程继续服务 |
| 自动触发 | save 900 1save 300 10save 60 10000 |
满足任一条件即自动执行 BGSAVE：900 秒内 1 次修改 / 300 秒内 10 次修改 / 60 秒内 10000 次修改 |
| 关闭时触发 | shutdown |
正常关闭 Redis 时自动执行一次 SAVE（若 AOF 未开启） |
4.1.2 RDB 文件结构
RDB 文件采用紧凑的二进制格式，包含文件头、数据库元数据、键值对数据、校验和等部分。其核心优势在于文件体积小、恢复速度快，适合用于全量备份和灾难恢复。
4.2 AOF 持久化：增量日志
AOF（Append Only File）以 追加日志 的方式记录每次写操作命令，恢复时通过重放日志重建数据。相比 RDB，AOF 提供了更高的数据安全性，但文件体积更大，恢复速度较慢。
4.2.1 写回策略
| 策略 | 配置值 | 写入时机 | 数据安全性 | 性能影响 |
|---|---|---|---|---|
| 每次写回 | always |
每个写命令执行后立即 fsync 到磁盘 | 最高，最多丢失 1 个命令 | 最慢，磁盘 IO 成为瓶颈 |
| 每秒写回 | everysec |
每秒执行一次 fsync | 较高，最多丢失 1 秒数据 | 适中，推荐生产环境使用 |
| 由系统决定 | no |
由操作系统决定何时刷盘 | 最低，可能丢失大量数据 | 最快，但不可控 |
4.2.2 AOF 重写机制
随着写操作不断累积，AOF 文件会持续膨胀。Redis 通过 AOF 重写 机制压缩文件体积：fork 子进程读取当前内存中的数据状态，生成一条等效的最小命令集，替换旧文件。重写过程同样基于写时复制，不阻塞主进程。
appendfsync everysec。同时设置 auto-aof-rewrite-percentage 100 和 auto-aof-rewrite-min-size 64mb，在文件增长到一定程度时自动触发重写。
4.3 混合持久化：RDB + AOF 融合
Redis 4.0 引入了 混合持久化（aof-use-rdb-preamble yes），将 RDB 的全量快照与 AOF 的增量日志结合。AOF 文件头部存储一份 RDB 格式的全量数据，尾部追加后续的增量写命令。恢复时先快速加载 RDB 部分，再回放少量 AOF 日志，兼顾了 RDB 的快速恢复和 AOF 的低数据丢失风险。
4.4 数据恢复策略与优先级
Redis 启动时根据配置文件的持久化设置自动加载数据。恢复顺序遵循以下优先级：
- 优先加载 AOF 文件：若
appendonly yes，Redis 会优先加载 AOF 文件。因为 AOF 通常比 RDB 包含更完整的数据。 - 次选 RDB 文件：若 AOF 未开启，则加载 RDB 文件。
- 无持久化文件：若两者均未配置或文件不存在，Redis 以空数据库启动。
redis-check-aof --fix 工具修复文件。RDB 文件损坏时同样可使用 redis-check-rdb 修复。
4.5 持久化方案对比与选型
| 对比维度 | RDB | AOF | 混合持久化 |
|---|---|---|---|
| 数据完整性 | 较低，可能丢失两次快照间的数据 | 高，最多丢失 1 秒数据（everysec） | 高，结合两者优势 |
| 文件体积 | 小，二进制压缩 | 大，文本协议 | 中等，RDB 部分压缩 |
| 恢复速度 | 快，直接加载二进制数据 | 慢，需逐条回放命令 | 较快，先加载 RDB 再回放少量日志 |
| 对主进程影响 | fork 时短暂阻塞，子进程写时复制 | 写回策略影响延迟，重写时 fork | 重写时生成 RDB 格式，fork 开销类似 |
| 推荐场景 | 冷备、主从全量同步、允许分钟级数据丢失 | 对数据安全要求高的核心业务 | 生产环境首选，兼顾性能与安全 |
4.6 生产配置最佳实践
# 开启混合持久化（Redis 4.0+）
aof-use-rdb-preamble yes
# AOF 配置
appendonly yes
appendfsync everysec
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# RDB 配置（作为 AOF 的补充备份）
save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb
dir /data/redis
# 安全配置
no-appendfsync-on-rewrite yes # 重写期间不执行 fsync，避免磁盘压力过大
4.7 持久化对缓存一致性的影响
在缓存一致性场景中，持久化机制直接影响数据恢复后的缓存状态：
- 宕机恢复后：Redis 加载持久化数据，此时缓存中的数据可能与数据库存在不一致。需要结合 过期时间 和 主动失效 策略，让缓存逐步回源数据库。
- 主从切换：新主库加载持久化文件后，若数据落后于旧主库，可能导致缓存雪崩。建议配合 哨兵 或 集群 的 数据同步延迟监控，确保切换后数据一致性。
- 混合持久化优势：在缓存场景中，混合持久化既能快速恢复大量缓存数据，又能通过 AOF 增量日志减少数据丢失，是保障缓存高可用的基石。