redis qps断崖下跌主因是appendfsync always导致主线程被fsync阻塞，aof_delayed_fsync和aof_pending_bio_fsync非零即证实刷盘滞后，iostat与iotop可验证i/o瓶颈，必须开启no-appendfsync-on-rewrite yes防重写雪崩。
看redis_aof_delayed_fsync是否持续非零
这个指标直接反映主线程AOF写入是否被磁盘IO拖住。只要它大于0，就说明appendfsync调用在排队等待刷盘，不是“没触发”，而是“触发了但卡住了”。生产环境应监控其75分位值是否长期 > 0，而不是只看是否为0。
常见误判是看到redis_aof_delayed_fsync偶尔跳1就忽略——其实连续5秒内出现3次以上非零，已表明IO调度开始吃紧。配合iostat -x 1观察await是否 > 15ms、%util是否 > 85%，能交叉验证。
查INFO persistence里aof_buffer_length和aof_rewrite_scheduled
aof_buffer_length持续 > 1MB，说明主线程写入速度远超磁盘吞吐能力；若同时aof_rewrite_scheduled为1，基本可断定重写即将触发IO雪崩——因为子进程一启动，就会叠加另一路写入压力。
注意：aof_rewrite_scheduled不等于正在重写，它只是标记“已排期”，真正开始前可能还有几十秒缓冲。此时应立刻检查auto-aof-rewrite-percentage是否设得太低（比如30），或auto-aof-rewrite-min-size是否过小（如64mb）。
- 若节点内存常驻在8GB以上，
auto-aof-rewrite-min-size建议 ≥1gb -
auto-aof-rewrite-percentage设为100比50更稳妥，避免小增量反复触发
对比重写前后used_memory_rss与磁盘write_bps
AOF重写本身不消耗主线程CPU，但会引发显著的used_memory_rss上涨——这不是内存泄漏，而是写时复制（COW）导致的页表拷贝。若重写期间used_memory_rss飙升 > 2GB，且write_bps（用iostat -d -x 1看）同步翻倍，说明磁盘已成瓶颈。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
特别注意：机械盘或混用分区时，write_bps可能虚高但tps（IOPS）卡在100以下，此时看avgrq-sz是否 > 32KB——越大越说明请求被合并，实际随机写能力已见底。
实操中，用CONFIG GET appendfsync确认当前策略，再结合CONFIG GET no-appendfsync-on-rewrite判断是否启用缓解措施。若为everysec但no-appendfsync-on-rewrite为no，几乎必然在重写期间出现毛刺。
用latency doctor定位IO毛刺是否关联重写周期
运行redis-cli --latency -h <host> -p <port></port></host>几秒后按enter触发诊断，重点看输出里是否出现command latency峰值与aof rewrite日志时间戳对齐。若对齐，问题根源就是IO争抢，不是网络或CPU。
更准的做法是抓取重写窗口内的延迟分布：redis-cli --latency-dist -h <host> -p <port></port></host>，观察P99延迟是否从0.3ms跳到8ms+。一旦确认，下一步不是调参数，而是检查磁盘物理隔离——比如df -T /data/redis-node-7001是否真指向独立NVMe设备，而非同一块SATA盘下的不同目录。
最容易被忽略的是rename()原子性依赖：AOF重写完成后的文件替换靠rename()系统调用，若挂载点是LVM快照或某些云盘虚拟层，该调用可能退化为copy+delete，瞬间放大IO压力。此时strace -p $(pgrep redis) -e trace=rename能看到明显耗时。
