要确认aof重写期间是否强刷物理磁盘，需交叉验证redis指标与系统i/o：若aof_delayed_fsync和aof_pending_bio_fsync持续大于0、iostat显示%util≈100%且w_await>50ms、used_memory_rss与used_memory差值超30%或vmswap非零，则确为物理磁盘饱和；同时须排除no-appendfsync-on-rewrite配置未生效、文件系统barrier强制落盘或不支持fsync原子语义（如nfs/overlayfs）等根因。
怎么确认AOF重写期间真的在强刷物理磁盘？
别只看aof_rewrite_in_progress为1就断定是重写导致卡顿——它只说明子进程已fork，不等于IO真在打满磁盘。真正要盯的是系统级I/O行为和Redis自身指标的交叉验证：
-
redis-cli info persistence | grep -E "aof_delayed_fsync|aof_pending_bio_fsync"：若两者持续大于0，说明fsync线程已在排队，主线程write被阻塞 -
iostat -x 1中%util接近100%且w_await> 50ms，基本可判定磁盘写入饱和 - 对比
used_memory_rss和used_memory：差值超过30%，大概率触发了COW页表复制，加剧IO压力 - 查
/proc/$(pidof redis-server)/status里的VmSwap：非零值说明内存不足，子进程fork后被迫swap，IO雪上加霜
为什么no-appendfsync-on-rewrite yes没起作用？
这个配置只对appendfsync everysec生效，如果你设的是always或no，它完全不触发。常见误配场景：
-
appendfsync always：强制同步，跳过fsync不可能，该配置被Redis忽略 -
appendfsync no：本来就不刷盘，无需跳过，配置无效 - 配置未生效：用
redis-cli config get no-appendfsync-on-rewrite确认返回值是yes，不是NO或空 - 重写未真正启动：
aof_pending_rewrite为1但aof_rewrite_in_progress始终为0，可能是fork()失败（vm.overcommit_memory=0+ 内存不足）
SSD云盘还卡，是不是文件系统在“假刷盘”？
很多团队换了NVMe仍卡顿，根因是文件系统挂载参数强制全链路落盘，把fsync拖成毫秒级。关键检查点：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
mount | grep $(redis-cli config get dir | awk '{print $2}')：看输出是否含barrier=1（ext4）或nobarrier缺失（XFS） -
xfs_info /path/to/redis/dir或tune2fs -l /dev/xxx | grep "Filesystem features"：确认journal存在且barrier未显式禁用 -
stat -f -c "%T" /path/to/redis/dir：返回nfs、overlay、fuse等即不支持fsync原子语义，重写必然卡住无报错 - 云盘场景额外验证：
echo 1 > /proc/sys/vm/drop_caches && time dd if=/dev/zero of=/path/to/test bs=4k count=10000 oflag=direct：裸盘写速低于5MB/s，说明底层IO能力不足
重写卡住但日志没报错，该查哪几行关键字段？
Redis日志静默失败时，90%问题藏在三个字段组合里，单看一个会误判：
-
aof_rewrite_in_progress= 1：子进程正在跑，但可能卡在fsync或write系统调用上 -
aof_pending_rewrite= 1：有重写请求排队，常见于bgsave未结束、fork()失败、或maxmemory触发OOM阻止新子进程 -
aof_last_bgrewrite_status≠ok：失败已发生，立刻查Redis日志里Could not rename（磁盘满/权限错）或Invalid argument（文件系统不支持fsync） - 顺手看
aof_base_size是否为0：为0代表从未成功重写过，自动触发机制已失效，必须手动执行BGREWRITEAOF激活
最易被忽略的是aof_last_fsync_time_sec——它只记录上次成功耗时，卡住或失败都不更新，盯着它等于白看。
