第6章 持久化：内存落盘之道
文档摘要
第6章 持久化：内存落盘之道 章节摘要：本章跟着一次断电走。Redis 的数据活在内存里，进程一死就清零；持久化就是提前准备好"复活甲"。两条路：RDB 定期把内存整体快照成紧凑文件，AOF 把每条写命令追加进日志。前者恢复快丢得多，后者丢得少恢复慢——混合持久化把两者的长处拼在了一起。 一条主线 一个真实的抉择：缓存实例重启，冷启动回源会把数据库打挂，所以需要 RDB 快速恢复"热度"；订单状态实例重启，一条都不能丢，所以需要 AOF 甚至 everysec 都嫌多。本章沿着"你能容忍丢多少数据、能容忍重启多久"这两个问题，把 RDB 的 fork 机制、AOF 的重写压缩、混合格式的嫁接方式逐一讲透。 沿途站点 6.
第6章 持久化：内存落盘之道
章节摘要：本章跟着一次断电走。Redis 的数据活在内存里，进程一死就清零；持久化就是提前准备好"复活甲"。两条路：RDB 定期把内存整体快照成紧凑文件，AOF 把每条写命令追加进日志。前者恢复快丢得多，后者丢得少恢复慢——混合持久化把两者的长处拼在了一起。
一条主线
一个真实的抉择：缓存实例重启，冷启动回源会把数据库打挂，所以需要 RDB 快速恢复"热度"；订单状态实例重启，一条都不能丢，所以需要 AOF 甚至 everysec 都嫌多。本章沿着"你能容忍丢多少数据、能容忍重启多久"这两个问题，把 RDB 的 fork 机制、AOF 的重写压缩、混合格式的嫁接方式逐一讲透。
沿途站点
- 6.1 RDB：fork 出子进程整体快照，写时复制让快照期间主线程照常服务。
- 6.2 AOF：先记命令后执行的三种刷盘频率，以及重写如何把日志减肥。
- 6.3 混合与选型：AOF 文件里嵌 RDB 格式的头，恢复既快又全。
两条路的数据流走向：
拐点与结论
转折点在 6.1 的写时复制：快照期间内存还在被改，怎么保证快照一致？答案是 fork 的那一刻数据就被"冻结"了——父进程后续的修改写进副本页，子进程看到的仍是旧页。这个操作系统机制是 RDB 一切优点的支点，也是"快照期间内存最多翻倍"这条容量纪律的来源。6.2 的 AOF 重写则是另一个方向的摊销：日志不能删，但可以"按结果重写"。
本章知识点清单
- 说出 BGSAVE 的三步：fork、子进程写临时文件、原子改名替换
- 解释写时复制如何让"边服务边快照"成立，以及内存峰值最多翻倍的由来
- 默写三种 appendfsync 策略的丢数据窗口与吞吐代价
- 描述 AOF 重写的"按结果重写历史"，以及重写期间新写入如何无缝缝进新文件
- 说出混合持久化的文件结构与恢复顺序，知道 5.0 起它就是默认
- 为缓存、会话、订单三类实例各选一套持久化组合并陈述理由
三类实例的选型一页纸，先背结论再学推理：
| 实例类型 | 推荐组合 | 丢数据容忍 | 恢复速度要求 |
|---|---|---|---|
| 纯缓存 | 只 RDB 或关持久化 | 全丢可接受 | 越快越好（怕冷启动打挂数据库） |
| 会话与一般业务 | 混合加 everysec | 一秒内 | 中等 |
| 订单与资金相关 | 混合加复制，真相入库 | 接近零 | 必须快，且丢了要能对账 |
配这张表的心法只有一句：先问业务能咽下多少丢失，再倒推配置。跳过这一问直接抄配置模板，出事前永远不知道自己站在哪一格。
本章的实验环境建议提前备好两样：一台敢于反复重启的测试实例（持久化的所有结论都要靠"写数据、杀进程、重启验收"来验证），以及一块能观察的磁盘（写入带宽与延迟决定两种持久化的体感）。读 6.1 时重点盯 fork 那一节的内存图，读 6.2 时重点算三种策略的丢失账——两处理解了，6.3 的混合方案就是水到渠成的加法。
章末的验收标准也直接给出：给你一台空实例与一份业务描述，你能在十分钟内写出它的持久化配置、说出丢数据窗口、并演示一次完整的"写入、断电、重启、清点损失"流程。做到了，本章就算真正过关。
读完你应该
- 解释 fork 与写时复制如何做到"边服务边快照"
- 说出三种 appendfsync 策略各自的丢数据窗口
- 手动触发 BGSAVE 与 BGREWRITEAOF 并解读耗时
- 为缓存、会话、订单三类实例分别选出持久化方案
- 配置混合持久化并说明它快在哪、全在哪
下一章的接力
单机的数据保住了，但单机本身还是会倒。第 7 章进入多副本世界：复制、哨兵、集群，让这套内存结构在机器故障下继续提供服务。