必须开启aof-rewrite-incremental-fsync yes，否则AOF重写会一次性刷数百MB脏页导致SSD写放大、await飙升至50ms+、%util达100%；同时应保持no-appendfsync-on-rewrite no，确保重写期间主线程仍按everysec规律fsync，避免完成瞬间日志积压。
aof-rewrite-incremental-fsync yes 是 SSD 场景下的强制要求
不开启 aof-rewrite-incremental-fsync yes，AOF 重写会一次性把整个重写缓冲区（可能几百 MB）通过 fdatasync() 刷盘，直接打满 SSD 的写队列。这不是“建议开启”，而是避免 await 突增至 50ms+、%util 持续 100% 的硬性配置。
该参数默认是 no，必须显式设为 yes 才生效。开启后，Redis 会在重写输出每 32MB 数据后主动调用一次 fdatasync()，把大块阻塞拆成多个小步，主线程和 I/O 调度器压力显著降低。
- 验证是否生效：重写期间执行
INFO persistence，观察aof_rewrite_in_progress:1时，iostat -x 1中的await是否稳定在 5ms 以内、%util是否未长期饱和 - 注意：该参数仅对 AOF 重写过程有效，不影响主线程的
appendfsync行为 - 若使用 NVMe SSD，还需确认内核调度器为
none：cat /sys/block/nvme0n1/queue/scheduler
no-appendfsync-on-rewrite no 才是正确搭配
很多用户误以为开启 no-appendfsync-on-rewrite yes 能“减轻 I/O 压力”，结果反而让 SSD 更卡。因为重写完成瞬间，主线程积压的大量待 fsync 日志会集中刷盘，形成更剧烈的写放大。
正确做法是保持 no-appendfsync-on-rewrite no（即默认值），确保即使在重写过程中，主线程仍按 appendfsync everysec 规律调用 fdatasync()。这样 I/O 压力被平摊，不会出现“重写刚结束就卡住”的毛刺。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 该配置仅在
appendfsync everysec下有意义；若用always，它会被忽略 - 禁用它后，需确保磁盘吞吐能力能承载“重写 + 主线程日志”双路写入——这也是为什么必须配专用 NVMe 盘，不能和 MySQL binlog 共盘
- 监控关键指标：
INFO persistence中的aof_delayed_fsync应长期为 0；若持续 > 0，说明 fsync 已开始排队，需检查磁盘或调整重写频率
auto-aof-rewrite-percentage 和 aof-rewrite-min-size 要配合增量 fsync 使用
aof-rewrite-incremental-fsync 解决的是“怎么刷”，而 auto-aof-rewrite-percentage 和 aof-rewrite-min-size 决定“什么时候刷”。三者不协同，优化效果会打折。
例如：若 aof-rewrite-min-size 过小（如 32MB），而业务写入节奏快，会导致重写过于频繁，哪怕每次都是增量刷盘，累积 I/O 仍可观；反之若设得过大（如 4GB），单次重写数据量太大，32MB 分段仍可能触发多次长延迟。
- SSD 场景推荐组合：
auto-aof-rewrite-percentage 80（早压）、aof-rewrite-min-size 256mb（防碎片） - 重写触发后，可通过
redis-cli BGREWRITEAOF手动补刀，但务必避开业务高峰，且确认aof_buffer_length当前 INFO persistence 查看） - 重写子进程本身也受内存影响：若 Redis 实际内存占用 > 4GB，
fork()开销明显，建议同时设置vm.overcommit_memory = 1
混合持久化（aof-use-rdb-preamble）在 SSD 上要谨慎启用
开启 aof-use-rdb-preamble yes 后，AOF 重写会先写一个 RDB 格式头部（紧凑二进制），再追加增量命令。这减少了文件体积，但破坏了纯顺序写模式——RDB 头部写完后，紧接着是大量小命令追加，极易触发 SSD 的垃圾回收（GC）和写放大。
尤其当业务写入以小 key 为主（如计数器、session）时，混合模式反而比纯 AOF 更伤 SSD 寿命与稳态延迟。除非你明确需要快速加载（RDB 部分恢复极快）且能接受写入模式劣化，否则 SSD 环境下建议保持 aof-use-rdb-preamble no。
- 纯 AOF 重写输出是连续大块写，对 SSD 友好；混合模式是“一大块 + 多小块”，I/O pattern 更接近随机写
- 若已启用混合模式，务必配合
aof-rewrite-incremental-fsync yes，否则 RDB 头部写入本身就会成为新的阻塞点 - 验证方式：重写完成后用
file appendonly.aof查看文件头，若含REDIS0011字样即为混合格式
aof-rewrite-incremental-fsync 当作可选开关，以及在启用它后却保留 no-appendfsync-on-rewrite yes。这两项组合错误，会让所有其他调优失效。 
