vault backup: 2026-05-26 20:58:30

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

@@ -188,6 +188,18 @@ dir /var/lib/redis                # AOF/RDB 文件存放目录
 > [!tip] 在线开启/关闭 AOF
 > 可以通过 `CONFIG SET appendonly yes` 在运行时开启 AOF，但需要注意：这会触发一次阻塞式的 AOF 初始化（类似 BGSAVE），**生产环境建议在低峰期操作**。关闭 AOF 同理：`CONFIG SET appendonly no`。
 
+> [!warning] "阻塞式 AOF 初始化" 到底阻塞了什么？
+> `CONFIG SET appendonly yes` 不能直接开始追加日志——Redis 必须先为内存中已有的数据生成一份完整的 AOF 基线文件。整个流程：fork 子进程 → 子进程遍历整个内存数据集 → 将所有 key 的当前状态写成 RESP 格式的 AOF 命令 → 写入 `appendonly.aof`。
+>
+> 说它"类似 BGSAVE"，是因为两者都是 `fork()` + 遍历内存写文件，面临的阻塞问题完全一样。但要注意——阻塞**不是**子进程"写 AOF 命令"这个动作造成的，而是两个阶段的叠加效应：
+>
+> 1. **fork 那一瞬间**（毫秒级）：Redis 单线程，fork 必须在主线程中完成。数据集越大，复制页表越慢，主线程在这几毫秒内完全停顿，无法处理任何请求
+> 2. **fork 之后的 COW 影响**（持续数秒~数分钟）：子进程遍历期间，主进程虽然可以继续处理请求，但每次写操作都可能触发 COW 页复制——内核会将被修改的内存页拷贝一份给子进程，内存压力骤增，间接拖慢主进程响应
+>
+> 所以准确地说，是**fork 的开销 + COW 的内存压力**让主进程变慢甚至短暂停顿，而非写文件本身。
+>
+> **最佳实践**：如果确定要开启 AOF，优先在 Redis 启动配置中直接设置 `appendonly yes`，让初始化发生在启动阶段而非运行时，对外部服务影响最小。
+
 Redis 7.x 的多文件目录结构：
 
 ```bash