info persistence 中反映 aof 磁盘压力的关键字段包括：aof_current_size、aof_base_size、aof_rewrite_in_progress、aof_last_bgrewrite_status 和 aof_pending_rewrite，它们共同指示 aof 文件膨胀、重写卡顿或失败等磁盘空间风险。
INFO persistence 返回哪些字段能反映 AOF 磁盘压力
INFO persistence 本身不直接返回磁盘剩余空间，但它暴露的几个关键字段是 AOF 是否正在“吃掉磁盘”的早期信号：
- aof_current_size：当前 AOF 文件字节数（注意不是磁盘占用峰值）
- aof_base_size：上一次重写完成时的 AOF 大小，用于计算膨胀率
- aof_rewrite_in_progress：是否正在重写（值为 1 时需警惕三份文件并存）
- aof_last_bgrewrite_status：上一次重写是否成功（err 很可能对应 No space left on device）
- aof_pending_rewrite：是否有重写被延迟挂起（常因磁盘满或 fork 失败）
如果 aof_current_size 持续飙升、aof_rewrite_in_progress 长时间卡在 1、且 aof_last_bgrewrite_status 变成 err，基本可以断定磁盘已触顶或即将触顶。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
如何用 shell + redis-cli 监控 AOF 增长速率
单看某次 INFO persistence 的 aof_current_size 没意义，必须测变化率。以下是一行可直接执行的监控命令：
watch -n 30 'echo -n "$(date +%H:%M:%S) | "; redis-cli INFO persistence | grep -E "aof_current_size|aof_rewrite_in_progress|aof_last_bgrewrite_status"'
重点关注两点：
- 连续几次观察中 aof_current_size 是否稳定增长（比如每分钟涨 50MB），说明业务写入量大且未触发重写
- aof_rewrite_in_progress:1 持续超过 5 分钟，大概率是重写被卡住——此时立刻查 df -h 和 ls -lh /var/lib/redis/appendonly.aof*，往往能看到 temp-rewriteaof-* 临时文件残留且体积巨大
为什么 aof_current_size 突然暴涨却不触发重写
这通常不是 Redis 故障，而是配置失当导致的“自我雪崩”：
- auto-aof-rewrite-percentage 设得太高（如 200），而实际 AOF 只比 aof_base_size 大 80%，永远达不到阈值
- auto-aof-rewrite-min-size 设得太低（如 64mb），但重写频繁失败后 Redis 会退避，不再尝试
- maxmemory 为 0 或过大，导致内存中过期键堆积，AOF 里仍记录大量无效写命令（如 SET key val EX 3600 后 key 已过期，但 AOF 不自动清理）
- dir 路径所在分区混放了日志、备份等其他文件，AOF 重写时临时文件无处落盘
磁盘满前最该检查的三个 config set 命令
不需要重启，立刻生效的止血操作：
- CONFIG SET maxmemory 4gb（设为物理内存的 70%，从源头压低 RDB/AOF 体积）
- CONFIG SET auto-aof-rewrite-percentage 50 + CONFIG SET auto-aof-rewrite-min-size 256mb（收紧重写条件，避免小文件反复重写）
- CONFIG SET dir /data/redis（确认并切换到独立大容量分区，务必先 mkdir -p /data/redis && chown redis:redis /data/redis）
执行后立即跑一次 redis-cli BGREWRITEAOF，再用 INFO persistence 观察 aof_rewrite_in_progress 是否降为 0、aof_last_bgrewrite_status 是否变回 ok。如果仍是 err，说明磁盘已满，必须先清理分区再操作。
