3. Redis 持久化机制：RDB快照原理与配置、AOF日志重写机制、混合持久化、生产环境选型策略
3.1 为什么需要持久化？
Redis 作为内存数据库，所有数据默认存储在内存中。一旦进程退出、服务器宕机或重启，内存数据将全部丢失。持久化机制将内存数据写入磁盘，确保重启后能快速恢复，是保障高可用和数据安全的基础。
核心目标：在性能与数据安全之间找到平衡点。不同的持久化策略决定了 Redis 在宕机后丢失多少数据、恢复多快。
3.2 RDB 快照原理与配置
3.2.1 工作原理
RDB（Redis Database）通过创建内存数据的二进制快照（dump.rdb）实现持久化。主进程 fork 出一个子进程，子进程将内存数据写入临时 RDB 文件，完成后替换旧文件。整个过程主进程不阻塞，继续处理客户端请求。
- 触发方式：手动（SAVE / BGSAVE）、自动（配置 save 指令）、关闭时（shutdown）、主从全量复制时。
- 核心机制：Copy-On-Write（写时复制）。fork 后父子进程共享内存页，子进程只读快照；主进程写操作时复制修改页，不影响子进程的持久化。
- 文件特点：单一文件、紧凑、恢复速度快，适合全量备份和灾难恢复。
3.2.2 配置参数
| 配置项 | 默认值 | 说明 |
|---|---|---|
save |
save 900 1 |
自动触发条件：save <seconds> <changes>，满足任一即执行 BGSAVE |
stop-writes-on-bgsave-error |
yes | BGSAVE 失败时是否停止写入，防止数据不一致 |
rdbcompression |
yes | 是否对 RDB 文件进行 LZF 压缩，节省磁盘空间 |
rdbchecksum |
yes | 写入/读取时是否使用 CRC64 校验，保证文件完整性 |
dbfilename |
dump.rdb | RDB 文件名 |
dir |
./ | RDB 文件及 AOF 文件存放目录 |
# 示例：生产环境常用配置
save 3600 1 # 1小时内至少1次变更
save 300 100 # 5分钟内至少100次变更
save 60 10000 # 1分钟内至少10000次变更
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename redis-6379.rdb
dir /data/redis/
注意：RDB 无法做到实时持久化。两次快照之间的数据在宕机时会全部丢失。如果业务对数据丢失零容忍，必须结合 AOF 或混合持久化使用。
3.3 AOF 日志重写机制
3.3.1 工作原理
AOF（Append Only File）以日志形式记录每次写操作指令，重启时回放所有指令重建数据。相比 RDB，AOF 提供了更高的数据安全性（可配置每秒同步、每次写入同步）。
- 写入流程：写命令 → 追加到 aof_buf → 根据 appendfsync 策略刷入磁盘 → 生成 AOF 文件。
- 重写机制：随着时间推移，AOF 文件会越来越大。Redis 通过 BGREWRITEAOF 命令或自动触发重写，将内存中的当前数据转换为最小指令集，生成新 AOF 文件替换旧文件。
- 重写过程：fork 子进程，子进程根据当前内存快照生成新 AOF；主进程继续处理请求并将增量命令写入重写缓冲区；重写完成后，主进程将缓冲区内容追加到新 AOF，原子替换旧文件。
3.3.2 配置参数
| 配置项 | 默认值 | 说明 |
|---|---|---|
appendonly |
no | 是否开启 AOF 持久化 |
appendfilename |
appendonly.aof | AOF 文件名 |
appendfsync |
everysec | 刷盘策略：always（每次写入）、everysec（每秒）、no（由 OS 决定） |
auto-aof-rewrite-percentage |
100 | AOF 文件增长超过上次重写后大小的百分比时触发重写 |
auto-aof-rewrite-min-size |
64mb | 触发重写的最小 AOF 文件大小 |
aof-load-truncated |
yes | 启动时加载截断的 AOF 文件是否继续（忽略尾部损坏数据） |
# 生产环境 AOF 配置示例
appendonly yes
appendfilename "redis-6379.aof"
appendfsync everysec
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 128mb
aof-load-truncated yes
no-appendfsync-on-rewrite yes # 重写期间不执行 fsync，防止磁盘 IO 阻塞
最佳实践：appendfsync 设置为 everysec 是性能和安全的折中方案。always 模式每次写入都 fsync，性能极差；no 模式由 OS 决定刷盘时机，宕机可能丢失大量数据。
3.4 混合持久化
3.4.1 为什么需要混合持久化？
Redis 4.0 引入混合持久化（aof-use-rdb-preamble），结合 RDB 的快速恢复和 AOF 的高安全性。AOF 重写时，子进程先将当前内存数据以 RDB 格式写入 AOF 文件头部，再将重写期间的增量命令以 AOF 格式追加到文件尾部。
- 文件结构：RDB 快照（头部） + AOF 增量日志（尾部）。
- 加载过程：先加载 RDB 部分快速恢复大部分数据，再回放 AOF 部分补全增量操作。
- 优势：重启恢复速度比纯 AOF 快数倍，数据安全性接近纯 AOF。
# 开启混合持久化（Redis 4.0+）
aof-use-rdb-preamble yes
推荐：Redis 4.0 及以上版本，生产环境强烈建议开启混合持久化。它几乎同时拥有 RDB 的恢复速度和 AOF 的数据安全性。
3.5 生产环境选型策略
3.5.1 三种持久化方案对比
| 维度 | RDB | AOF | 混合持久化 |
|---|---|---|---|
| 数据安全性 | 低（丢失两次快照间数据） | 高（最多丢失1秒数据） | 高（最多丢失1秒数据） |
| 恢复速度 | 快（直接加载二进制快照） | 慢（逐条回放指令） | 较快（RDB 快照 + 少量 AOF 回放） |
| 文件大小 | 小（压缩二进制） | 大（文本指令） | 中等（RDB 压缩 + AOF 增量） |
| 对性能影响 | fork 时短暂阻塞，子进程写磁盘 | 写操作频繁 fsync，IO 压力大 | 重写时 fork，增量写 AOF |
| 适用场景 | 缓存、可容忍分钟级数据丢失 | 金融、交易等零容忍场景 | 通用生产环境首选 |
3.5.2 选型决策流程
- 业务容忍丢失多少数据？分钟级 → RDB；秒级 → AOF 或混合。
- 恢复速度要求？秒级恢复 → RDB 或混合；分钟级恢复 → AOF。
- 磁盘 IO 是否充裕？IO 紧张 → RDB（写频率低）；IO 充裕 → AOF 或混合。
- Redis 版本？4.0 以下 → RDB + AOF 同时开启；4.0 以上 → 混合持久化。
生产推荐方案：
- Redis 4.0+：开启混合持久化（
aof-use-rdb-preamble yes），appendfsync everysec。 - Redis 2.8/3.x：同时开启 RDB 和 AOF，RDB 用于快速恢复，AOF 用于数据安全。
- 纯缓存场景（可接受重启丢数据）：仅开启 RDB，关闭 AOF 以提升写入性能。
3.6 持久化流程全景图
3.7 常见问题与避坑指南
| 问题 | 原因 | 解决方案 |
|---|---|---|
| fork 阻塞导致延迟抖动 | fork 子进程时复制页表，内存越大耗时越长 | 控制实例内存 < 8GB；使用物理机而非容器；开启 lazyfree-lazy-eviction yes |
| AOF 文件无限增长 | 未配置自动重写或重写条件过高 | 设置合理的 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size |
| RDB 文件损坏 | 磁盘故障、写入中断 | 开启 rdbchecksum yes；使用 redis-check-rdb 工具修复 |
| AOF 文件尾部截断 | 宕机导致最后一条指令未写完 | 设置 aof-load-truncated yes，启动时自动忽略损坏尾部 |
| 同时开启 RDB + AOF 时恢复顺序 | Redis 优先加载 AOF，AOF 完整度更高 | 确保 AOF 文件完整；如果 AOF 关闭，则加载 RDB |
生产避坑：不要在 Redis 高负载时手动执行 BGSAVE 或 BGREWRITEAOF，fork 操作可能引发内存抖动和延迟飙升。建议将自动触发时间错峰设置在业务低峰期。