219 lines
8.6 KiB
Markdown
219 lines
8.6 KiB
Markdown
---
|
||
tags: [Redis, 缓存, 持久化, AOF]
|
||
create time: 2026-05-15 18:13
|
||
---
|
||
|
||
# AOF 持久化
|
||
|
||
## 概述
|
||
|
||
AOF（Append Only File）以**追加写日志**的方式记录每个写操作。相比 RDB 的快照式恢复，AOF 提供更高的数据安全性——你可以根据策略做到**不丢数据、丢 1 秒、或丢 N 条**。代价是文件更大、恢复更慢。
|
||
|
||
## 核心机制
|
||
|
||
### 命令追加过程
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
Client["客户端写入"] --> Server["Redis 主线程<br/>执行命令 + 返回结果"]
|
||
Server --> Buffer["aof_buffer<br/>内核/用户态缓冲区"]
|
||
Buffer --> FSyncPolicy{"刷新策略？"}
|
||
FSyncPolicy -->|everysec| KernelBuf["操作系统页缓存"]
|
||
KernelBuf --> Disk["磁盘 aof 文件"]
|
||
FSyncPolicy -->|always| Disk
|
||
FSyncPolicy -->|no| OSPage["交给 OS 自己 flush"]
|
||
|
||
style Server fill:#f9d,stroke:#96c
|
||
style Disk fill:#dfd,stroke:#6c6
|
||
```
|
||
|
||
> [!TIP] 一条命令是怎么落到磁盘的？
|
||
> 1. 客户端发送命令 → 2. Redis 在主线程执行并返回结果 → 3. 同时将命令追加到 `aof_buffer` → 4. 根据 `appendfsync` 策略最终刷入磁盘。整个过程对主线程几乎是异步的。
|
||
|
||
### 刷新策略配置
|
||
|
||
```conf
|
||
# appendfsync always # 每次写入都 fsync -> 最安全，性能差
|
||
appendfsync everysec # 每秒 fsync <- 推荐（最佳平衡）
|
||
# appendfsync no # 完全依赖 OS -> 性能最好，风险最高
|
||
```
|
||
|
||
| 策略 | 丢失风险 | 吞吐量 (ops/s) | 适用场景 |
|
||
|------|---------|---------------|---------|
|
||
| `always` | 零丢失 | ~900 | 金融级要求（极少用） |
|
||
| `everysec` | 最多丢 1 秒 | ~74k | **生产标准配置** |
|
||
| `no` | OS 决定，可能丢大量 | ~93k | 可接受全量丢失的场景 |
|
||
|
||
> [!TIP] everysec 的性能真相
|
||
> `everysec` 不会阻塞主线程——它把 fsync 放到单独的后台线程。即使某个 fsync 花了 2s（磁盘卡顿），也只是这一秒的写入被推迟到下一周期，不会影响主线程。
|
||
|
||
## AOF 重写（Rewrite）
|
||
|
||
AOF 文件会不断增长，需要定期重写来去除无效命令（如 key 被 DEL 后又 SET）。
|
||
|
||
### 重写触发条件
|
||
|
||
```conf
|
||
auto-aof-rewrite-percentage 100 # AOF 比上次 rewrite 后增大的百分比
|
||
auto-aof-rewrite-min-size 64mb # AOF 最小绝对大小（避免刚启动就 rewrite）
|
||
```
|
||
|
||
示例：当前 AOF = 128MB，上次 rewrite 后大小 = 64MB
|
||
- 增量 = 128 - 64 = 64MB
|
||
- 增量占比 = 64 / 64 = 100% -> 触发 rewrite
|
||
- 但如果当前 AOF < 64MB -> 不触发
|
||
|
||
> [!QUESTION] 如果设置 auto-aof-rewrite-min-size 太大或太小会发生什么？
|
||
> - **太大**：AOF 膨胀了很久才触发重写，磁盘空间浪费严重
|
||
> - **太小**：频繁重写，增加不必要的 CPU 和 IO 开销
|
||
>
|
||
> 这本质上是一个「文件瘦身频率」的工程权衡题。
|
||
|
||
### 重写过程（类似 RDB fork）
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant S as Redis Server
|
||
participant P as 主进程
|
||
child CG as Rewriter Child
|
||
participant C as 重写子进程
|
||
participant Log as appendonly.aof
|
||
participant NewLog as appendonly.aof_rewrite_tmp
|
||
end
|
||
|
||
S->>P: BGREWRITEAOF
|
||
P->>S: OK
|
||
P->>C: fork() 子进程
|
||
C->>NewLog: fork 时刻起遍历内存 -> 重写为精简命令
|
||
Note over P,C: Main process continues serving requests
|
||
loop 每个新写命令
|
||
P->>Log: 追加原始命令
|
||
P->>C: 同时写入 aof_rewrite_buf<br/>（重写期间的新操作）
|
||
end
|
||
C->>NewLog: 追加 aof_rewrite_buf 中的内容
|
||
C->>P: 完成
|
||
P->>Log: rename(原 -> 旧.bak, 新 -> 当前)
|
||
```
|
||
|
||
> [!WARNING] 重写的内存开销
|
||
> fork 后重写子进程也使用 COW 机制。如果你的 AOF 正在持续增长且写入量大，可能需要评估可用内存是否足够支撑 fork 的 COW 副本。在 100GB+ 的 Redis 实例上，一次 fork 可能导致额外的几 GB 内存占用。
|
||
|
||
## AOF 开启方式
|
||
|
||
```conf
|
||
appendonly yes # 开启 AOF
|
||
appendfilename "appendonly.aof" # AOF 文件名
|
||
dir /var/lib/redis # AOF/RDB 文件存放目录
|
||
```
|
||
|
||
```bash
|
||
# Redis 7.x 目录结构（新版本使用多文件目录而非单文件）
|
||
ls /var/lib/redis/appendonlydir/
|
||
total 256M
|
||
drwxr-x--- 2 redis redis 4.0K May 15 18:00 .
|
||
drwxr-x--- 2 redis redis 4.0K May 15 18:00 ..
|
||
-rw-r----- 1 redis redis 16K May 15 18:00 manifest.aof
|
||
-rw-r----- 1 redis redis 128M May 15 18:00 base.rdb
|
||
-rw-r----- 1 redis redis 128M May 15 18:01 incr-0000000000000003.aof
|
||
```
|
||
|
||
### 思考：为什么 AOF 会持续增长？
|
||
|
||
想象以下操作序列：`SET x 1 -> SET x 2 -> SET x 3 -> DEL x`。如果不做处理，AOF 中会记录这 4 条命令，但 key `x` 已经不存在了——这些写入了磁盘却没有任何价值。这就是为什么需要**重写**。
|
||
|
||
## 混合持久化（Hybrid Persistence）
|
||
|
||
混合持久化是 Redis 4.0 引入、Redis 7 默认开启的特性——在 AOF 重写时，先用 RDB 快照全量备份当前内存状态，再用 AOF 追加增量变化。
|
||
|
||
```conf
|
||
# redis.conf
|
||
aof-use-rdb-preamble yes # 开启混合持久化（默认值）
|
||
```
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
BG["BGREWRITEAOF"] --> Fork["fork 子进程"]
|
||
Fork --> RDBPart["RDB 全量部分<br/>二进制快照，写入极快"]
|
||
Fork --> AOFPart["AOF 增量部分<br/>仅含 fork 后的写操作"]
|
||
RDBPart --> Merge["合并为临时文件"]
|
||
AOFPart --> Merge
|
||
Merge --> Rename["原子 rename 替换"]
|
||
|
||
style RDBPart fill:#bbf,stroke:#66c
|
||
style AOFPart fill:#dfd,stroke:#090
|
||
style Merge fill:#ffd,stroke:#cc0
|
||
```
|
||
|
||
**好处有两个：**
|
||
1. **恢复速度快**：启动时先加载 RDB 全量快照（二进制格式比解析 AOF 命令快 10~100 倍），再回放少量 AOF 增量命令
|
||
2. **文件体积小**：相比纯 AOF 记录每条操作指令，混合模式下文件通常缩小 70%~90%
|
||
|
||
> [!WARNING] 恢复流程的变化
|
||
> 混合模式下，Redis 启动时先读取 `base.rdb` 还原全部数据，再逐条执行增量 `.aof` 段中的命令。如果只保留 AOF 段而删除 `base.rdb`，恢复将退化为纯 AOF 模式，速度大幅下降。
|
||
|
||
## AOF vs RDB 对比
|
||
|
||
| 维度 | AOF (`everysec`) | RDB（典型配置） |
|
||
|------|-----------------|----------------|
|
||
| 数据安全性 | ⭐⭐⭐ 最多丢 1s | ⭐ 可能丢数分钟 ~ 小时 |
|
||
| 恢复速度 | ⭐⭐ 较慢（需逐条 replay） | ⭐⭐⭐ 快（二进制直接加载） |
|
||
| CPU 开销 | ⭐⭐ 每秒一次 fsync | ⭐ 仅在 fork 时短暂增长 |
|
||
| 磁盘 IO | ⭐⭐ 持续写入日志 | ⭐ 仅在快照间隔触发 |
|
||
| 文件大小 | ⭐ 较大（逐条记录） | ⭐⭐⭐ 较小（二进制压缩） |
|
||
| 数据丢失窗口 | <= 1 秒 | = save 间隔时间 |
|
||
|
||
> [!QUESTION] 什么时候该用 RDB 而不是 AOF？
|
||
> 如果你的业务场景是**缓存而非数据库**——数据可以重新构建或允许短暂丢失，那 RDB 就够了。只有当数据丢失会造成长期损失（如订单、余额）时，才需要上 AOF。
|
||
|
||
## AOF 故障恢复
|
||
|
||
```bash
|
||
# 如果 AOF 损坏（断电等原因导致截断）
|
||
redis-server --repair appendonly.aof
|
||
# 或 Redis 7 下修复整个目录
|
||
redis-server --fix appendonlydir/aof-manifest
|
||
```
|
||
|
||
### fsync 失败时的行为
|
||
|
||
```
|
||
fsync -> EIO（磁盘错误）
|
||
↓
|
||
ERROR "I/O error writing to APPEND ONLY FILE..."
|
||
↓
|
||
立即 SHUTDOWN NOSAVE（停止服务防止数据进一步损坏）
|
||
```
|
||
|
||
> [!NOTE] Redis 为什么会主动 shutdown？
|
||
> 这是一种「fail-fast」设计哲学。AOF 的核心价值就是数据安全，当底层磁盘出现问题时，继续运行只会导致更多数据静默损坏。宁可停机也不能让用户在「不确定」的数据上继续业务。
|
||
|
||
> [!WARNING] AOF 不是万能的
|
||
> - AOF 修复工具只能恢复大部分，极端情况下会有部分命令丢失
|
||
> - 定期做冷备份（RDB 迁移到 OSS/S3）仍然是必须的兜底手段
|
||
|
||
## AOF vs RDB 选型决策树
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
Start{"你的首要需求是？"} -->|"数据安全第一"| AOF["AOF everysec"]
|
||
Start -->|"恢复速度第一"| RDB["RDB 仅"]
|
||
Start -->|"两者兼顾"| HYBRID["混合持久化"]
|
||
|
||
HYBRID --> Check{"数据重要性极高？"}
|
||
Check -->|"是"| ALWAYS["AOF always<br/>+ 每天冷备"]
|
||
Check -->|"否"| EVERYSEC["AOF everysec<br/>+ 混合持久化"]
|
||
|
||
style HYBRID fill:#dfd,stroke:#090
|
||
style ALWAYS fill:#fdd,stroke:#900
|
||
style EVERYSEC fill:#dfd,stroke:#090
|
||
```
|
||
|
||
> [!TIP] 生产环境黄金组合
|
||
> `AOF everysec + 混合持久化 + 定时 rdb 冷备到对象存储`——几乎覆盖所有常见场景。
|
||
|
||
## 关联笔记
|
||
|
||
- [[hhs/Redis/04-RDB持久化]] — RDB 快照机制
|
||
- [[hhs/Redis/06-主从与哨兵]] — 哨兵监控中 AOF 状态检查
|
||
- [[hhs/Redis/09-运维调优]] — AOF 文件膨胀治理
|