appendfsync策略的实际性能损耗由刷盘阻塞模式决定：always完全同步阻塞，everysec在磁盘过载时主线程被write阻塞，no则不落盘；需结合aof_delayed_fsync、await等指标与iostat/iotop验证真实瓶颈。
看 appendfsync 策略对应的实际延迟叠加方式
性能损耗不是固定百分比，而是由刷盘策略决定的阻塞模式。不同策略下，主线程被拖住的方式完全不同：
-
always：每次写命令后必须等fsync()返回，主线程完全同步阻塞。SSD上单次耗时 0.2–1ms，但高并发下排队导致 P99 延迟跳到 20–50ms，QPS 直接被压到磁盘随机写 IOPS 上限（机械盘 ≈150，SATA SSD ≈3000） -
everysec：主线程只做write()，不等fsync()；后台线程每秒刷一次。但若磁盘已满负荷（iostat -x 1显示%util长期 100%，await > 10ms），后台fsync滞后，主线程下一次write()就会被阻塞——此时aof_delayed_fsync指标会每秒涨几十上百 -
no：仅调用write()，数据留在内核页缓存，不落盘。性能接近禁用 AOF，但断电即丢全部未刷缓冲区数据
用 INFO persistence 和系统工具交叉验证真实瓶颈
不能只看配置写了 everysec 就认为安全。实际是否被拖慢，得看指标和 I/O 行为是否匹配：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 运行
redis-cli info persistence | grep -E "aof_delayed_fsync|aof_pending_bio_fsync"：两个值非零，说明刷盘已滞后，主线程正在排队 - 执行
iotop -o -a，过滤redis-server进程，观察WRITE列是否稳定在几百 KB/s —— 这是fsync反复掐住写入节奏的典型特征 - 用
iostat -x 1看w/s是否卡在磁盘理论 IOPS 极限附近，await是否持续高于 5ms。云盘尤其要注意，标称 IOPS 往往只有实测的 6–8 折
注意 no-appendfsync-on-rewrite yes 不是可选项，是保命配置
AOF 重写（bgrewriteaof）期间，子进程读磁盘 + 主线程写 AOF 缓冲区 + 后台线程刷盘三者争抢 I/O，极易触发雪崩。常见现象是重写一启动，QPS 瞬间归零，aof_delayed_fsync 爆涨。
- 必须设为
yes，否则重写时主线程的write()会被强制暂停，AOF 缓冲区积压暴涨 - 代价是重写窗口期最多丢失 1 秒数据（与
everysec本身一致），但换来的是 QPS 不断崖 - 这个配置一旦漏掉，即使磁盘是 NVMe，也会在重写时刻暴露成性能单点
混合持久化开启后，AOF 重写不再等于纯文本追加
Redis 4.0+ 开启 aof-use-rdb-preamble yes 后，AOF 重写会先写一段 RDB 格式二进制头，再追加增量命令。这显著缩短了重放时间，但对写性能影响有限——真正影响写吞吐的，仍是 appendfsync 策略和磁盘 I/O 调度能力。
- 重写过程本身仍需 fork 子进程、读内存、序列化、写文件，CPU 和内存带宽压力仍在
- 重写完成后，新 AOF 文件体积更小，但主线程写入逻辑不变，
aof_buf→write()→fsync()链路没变 - 如果业务写入量极大（如每秒数万 SET），建议配合
aof-rewrite-incremental-fsync yes，让重写分批刷盘，避免一次性压垮 I/O
aof_delayed_fsync 和磁盘 await 这两个信号。它们不骗人，一涨就说明主线程已经在等磁盘了——这时候调优不是改 Redis 参数，而是得去查 I/O 路径：挂载选项、队列深度、是否和其他服务共用磁盘。
