03 - 持久化
定位: Redis 的数据安全保障机制——内存数据如何可靠落地 面试高频度: ⭐⭐⭐⭐⭐
一、板块在体系中的位置
二、知识全景图
三、子专题导航
| # | 主题 | 面试频率 | 核心内容 |
|---|---|---|---|
| **03.1 RDB** | RDB 快照机制 | ⭐⭐⭐⭐ | save/bgsave、写时复制（COW）、fork 对性能的影响 |
| **03.2 AOF** | AOF 日志机制 | ⭐⭐⭐⭐⭐ | 写后日志、三种 fsync 策略、AOF rewrite、阻塞风险 |
| **03.3 混合持久化** | 混合持久化与最佳实践 | ⭐⭐⭐⭐ | RDB+AOF 混合、数据恢复方案、生产配置建议 |
四、核心考点速记
考点 1：RDB 和 AOF 的选择
RDB: 全量快照，恢复快，可能丢数据（上次快照之后的数据） AOF: 增量日志，丢数据少（最多 1 秒），恢复慢，文件大
生产建议：两个都开（混合持久化），RDB 做全量基础 + AOF 做增量补全
考点 2：AOF 的三种 fsync 策略
always: 每次写入都 fsync → 最安全但最慢（~100 QPS） everysec: 每秒 fsync → 安全（最多丢 1 秒数据） no: 由 OS 决定 → 最快但可能丢 30 秒数据
生产推荐：everysec（兼顾安全与性能）
考点 3：RDB 的写时复制（COW）
fork() 时父子进程共享内存页
- 子进程写 RDB（读取共享页）
- 父进程修改数据 → 触发 COW
- → 复制被修改的页
- → 子进程继续读旧页（快照）
- → 父进程修改新页（实时数据）
内存翻倍风险：如果 bgsave 期间父进程大量写，COW 复制大量页面 → 内存翻倍
📚 相关板块
- **核心数据结构** — 持久化保存的是什么
- **高可用集群** — 持久化是主从复制的基础
- **总纲设计文档**