vault backup: 2026-05-24 21:18:14

hhs/Redis/05-AOF持久化.md

@@ -181,49 +181,12 @@ ls /var/lib/redis/appendonlydir/
 
 ## 混合持久化（Hybrid Persistence）
 
-混合持久化是 Redis 4.0 引入、Redis 7 默认开启的特性，它解决了 AOF 重写的一个尴尬问题：**重写时到底该生成 RDB 还是 AOF？**
-
-> [!question] 纯 AOF 重写的痛点
-> 纯 AOF 重写需要把每个 key 的当前状态都转成 SET/HSET 等命令写入文件。当实例有几十万个 key 时，这些命令序列化+解析的过程会显著拖慢恢复速度。而 RDB 是二进制格式，加载速度比逐条执行 AOF 命令快 10~100 倍。
+> [!tip] 混合持久化是 AOF 重写的"终极形态"
+> Redis 4.0 引入、Redis 7 默认开启。核心思路：AOF **重写**时先写 RDB 全量快照作为"底子"，再追加增量 AOF 命令作为"补丁"——恢复时先加载 RDB（秒级），再回放少量增量 AOF（补齐数据）。
 >
-> 混合持久化的答案很简单：**两种都用**。重写时先写 RDB 全量快照作为"底子"，再追加一小段 AOF 增量命令作为"补丁"。
-
-```conf
-# redis.conf
-aof-use-rdb-preamble yes   # 开启混合持久化（默认值）
-```
-
-重写后生成的文件结构如下：
-
-```mermaid
-flowchart TD
-    subgraph NEW_AOF["重写后的新 AOF 文件"]
-        direction LR
-        RDB["RDB 二进制块<br/>(全量数据快照)"] --> AOF["AOF 增量块<br/>(仅重写期间的新写操作)"]
-    end
-
-    Fork["fork 子进程"] --> RDB
-    Fork --> AOF
-    RDB --> Merge["合并写入临时文件"]
-    AOF --> Merge
-    Merge --> Rename["原子 rename 替换旧文件"]
-
-    style RDB fill:#bbf,stroke:#66c
-    style AOF fill:#dfd,stroke:#090
-    style Merge fill:#ffd,stroke:#cc0
-```
-
-**好处有两个：**
-1. **恢复速度快**：启动时先加载 RDB 二进制快照（顺序读、无需解析命令语法），再回放少量 AOF 增量命令。即使 AOF 增量段有几十 MB，相比从头解析几十 GB 的纯 AOF 命令也快得多
-2. **文件体积小**：RDB 本身就是压缩的二进制格式，比等量数据的纯 AOF 文本命令小 70%~90%
-
-> [!warning] Redis 7 的多文件目录结构
-> Redis 7 不再使用单个 AOF 文件，而是采用多文件目录结构：
-> - `base.rdb`：AOF 重写时生成的 RDB 全量快照
-> - `incr-*.aof`：增量 AOF 文件（记录重写之后的新写操作）
-> - `manifest.aof`：文件清单，记录哪些文件属于同一个 AOF 实例
+> **在 AOF 视角下**：重写后生成的文件不再全是文本命令，而是 `RDB 二进制基线 + AOF 增量日志` 的混合结构。好处是恢复速度快（接近纯 RDB）且数据安全性高（接近纯 AOF）。
 >
-> 恢复时 Redis 会按 manifest 加载：先加载 `base.rdb`，再按顺序回放所有 `incr-*.aof`。如果删除了 `base.rdb`，恢复退化为纯 AOF 模式，速度会大幅下降。
+> 详细的文件结构、原理图解和配置方式，参见 [[hhs/Redis/04-RDB持久化#Redis 混合持久化（推荐）|混合持久化完整章节]]。
 
 ## AOF vs RDB 对比
 
@@ -308,4 +271,4 @@ flowchart TD
 
 - [[hhs/Redis/04-RDB持久化]] — RDB 快照机制
 - [[hhs/Redis/06-主从与哨兵]] — 哨兵监控中 AOF 状态检查
-- [[hhs/Redis/09-运维调优]] — AOF 文件膨胀治理
+- [[hhs/Redis/11-运维与性能调优]] — AOF 文件膨胀治理