AOF 为什么会膨胀
AOF 记录的是写命令历史而不是数据的最终状态，同一个键反复修改就会被不断追加，体积可能远超数据集本身。增长有两个来源：命令历史持续累积，以及长期没有触发重写。控制手段是配合自动重写阈值或人工执行 BGREWRITEAOF，同时给 AOF 目录所在磁盘设置剩余空间告警，因为磁盘写满会直接触发写保护，写入立刻被拒。
基本信息
| 增长原因 | 命令历史累积，且未触发重写 |
|---|---|
| 压缩手段 | BGREWRITEAOF，或按百分比与最小体积自动触发 |
| 重写峰值 | 旧文件与新文件需要在磁盘上同时存在 |
| 监控项 | 目录大小、磁盘剩余空间、当前与基线体积 |
| 危险线 | 磁盘写满触发写保护，写命令被拒 |
典型使用场景
- AOF 目录持续膨胀，需要判断是业务写入猛还是重写没触发
- 新实例上线前估算持久化所需磁盘容量下限
- 重写前后对比体积确认压缩效果是否符合预期
- 制定磁盘水位告警阈值并纳入容量评审
- 体积异常时排查是否存在大事务、批量删除或异常写入模式
体积查看
体积查看
du -sh /data/redis/appendonlydir/ # AOF 目录当前实际占用
df -h /data/redis # 所在磁盘剩余空间
redis-cli INFO persistence | grep -E 'aof_current_size|aof_base_size'
redis-cli CONFIG GET auto-aof-rewrite-percentage auto-aof-rewrite-min-size
redis-cli BGREWRITEAOF # 手工触发一次重写压缩体积指标怎么读
| 指标 | 含义 | 异常表现 |
|---|---|---|
| aof_current_size | 当前 AOF 体积 | 与基线同步上涨说明写入持续增长 |
| aof_base_size | 上次重写后的基线体积 | 长期不变而当前值剧增说明重写没触发 |
| automatic 百分比阈值 | 允许相对基线增长的触发比例 | 设置过大时体积先膨胀很多才重写 |
| 最小触发体积 | 低于该值不触发重写 | 设置太小会导致重写过于频繁 |
| 目录实际占用 | 文件系统层面的统计 | 与内存指标口径不同，容量规划以它为准 |
重写后的基线体积通常与数据集规模同级，可用它估算磁盘下限：数据集大小加重写期间的增量，再加新旧文件同存的临时峰值。
关闭 AOF 的实例不适用上述指标；只开 RDB 时快照体积更接近数据集实际大小，两者不能用同一套阈值衡量。