redis aof缓冲区（aof_buf）位于内存中，不计入used_memory，其当前字节数可通过info persistence命令中的aof_buffer_length字段查看，该值表示未刷盘的待写内容大小。
Redis AOF缓冲区在哪看？用 info persistence 查实时状态
Redis 的 AOF 缓冲区（aof_buf）是主线程写入 AOF 文件前的内存暂存区，它不计入 used_memory，但会持续增长直到 fsync 或 rewrite 触发。直接查不到它的独立大小，但可通过 info persistence 中两个关键字段交叉判断：
-
aof_buffer_length：当前 AOF 缓冲区实际占用字节数（即未刷盘的待写内容） -
aof_pending_bio_fsync：等待后台 I/O 线程执行 fsync 的请求数（非字节数，但值大说明刷盘滞后）
注意：aof_buffer_length 在 AOF 关闭时为 0；开启但未写入时也为 0；只有客户端有写命令、且尚未触发 fsync/rewrite 时才非零。别误把它当成磁盘 AOF 文件大小——那是 aof_current_size。
为什么 aof_buffer_length 会突然飙升？常见诱因有哪些
缓冲区膨胀不是独立故障，而是 I/O 压力或配置失配的信号。重点排查以下场景：
- AOF 配置为
appendfsync everysec，但后台 fsync 线程被阻塞（如磁盘高 iowait、ext4 日志模式异常） - 开启了
aof-rewrite-incremental-fsync yes，但 rewrite 进程本身卡在慢盘或 CPU 资源争抢中 - 写流量突增 + 子进程 fork 耗时长（尤其大内存实例），导致 rewrite 周期拉长，旧缓冲持续累积
- 使用了
no-appendfsync-on-rewrite yes，但 rewrite 时间过长，主线程 aof_buf 持续堆积
此时 aof_pending_bio_fsync 往往 > 0，且 aof_buffer_length 持续 > 数 MB，就该预警了。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
如何设置有效监控阈值？别只盯绝对值
单纯设「aof_buffer_length > 10MB」报警容易误报。更稳妥的方式是结合速率和上下文：
- 监控 30 秒内
aof_buffer_length的 delta：若连续 3 次增量 > 2MB，说明写入远超刷盘能力 - 当
aof_pending_bio_fsync> 5 且aof_buffer_length> 5MB 同时成立，大概率已出现 I/O 卡顿 - 对比
instantaneous_ops_per_sec：若 QPS > 5k 但aof_buffer_length平稳
Prometheus + Redis exporter 可轻松实现上述复合指标采集，关键是把 aof_buffer_length 当作「流速失衡指示器」，而非静态内存用量。
内存占用混淆点：AOF 缓冲区不进 used_memory，但子进程会复制它
这是最容易忽略的隐性成本：aof_buffer_length 本身不计入 used_memory，但在 fork AOF rewrite 子进程时，Linux 写时复制（COW）机制会让子进程初始共享这部分内存页。一旦主线程继续写入 aof_buf，就会触发实际内存分配——表现为 mem_fragmentation_ratio 突升、RSS 快速上涨。
所以即使 used_memory 看着正常，若 aof_buffer_length 长期 > 3MB，且实例 RSS 比 used_memory_rss 高出 20% 以上，就要怀疑 COW 开销了。此时降负载、调小 auto-aof-rewrite-min-size、或切到 appendfsync always（慎用）可能比加内存更治本。
