Redis AOF开启后变慢的关键在于fsync策略，设为always会导致每次write后强制刷盘，使吞吐下降一个数量级；everysec模式下需关注aof_delayed_fsync和aof_buffer_length等指标，并通过内核参数、文件系统挂载选项及磁盘隔离优化性能。
Redis AOF 为什么一开就变慢？关键在 fsync 策略
开启 AOF 后写入性能明显下降，大概率不是 Redis 本身扛不住，而是 fsync 被设成了 always。这个配置会让每次 write 后立刻触发磁盘强制刷写，把网络延迟、命令排队、磁盘 I/O 全部串行化，吞吐直接掉一个数量级。
真实场景中，除非你运行的是金融级强一致性系统（且能接受单节点写入 always 几乎没有实用价值。它牺牲的是可量化的性能，换来的只是「最多丢失 0 个命令」的理论保障——而实际还受内核页缓存、文件系统、磁盘断电等多层影响。
-
appendfsync always：每条命令后调fsync()，延迟高、吞吐低，适合极少数对数据零容忍丢失的场景 -
appendfsync everysec：默认值，主线程把命令写入内核缓冲区后返回，后台线程每秒fsync一次；平均延迟低，最多丢失 1 秒数据 -
appendfsync no：完全交由操作系统决定何时刷盘，性能最好，但崩溃时可能丢失几十秒甚至更多数据
如何验证当前 fsync 是否成为瓶颈？
别猜，直接看指标。用 redis-cli info persistence 查看 aof_delayed_fsync 字段——它表示因内核缓冲区满或后台 fsync 正在进行，导致主线程被迫等待的次数。如果这个值持续增长（比如每分钟增加上百次），说明 everysec 模式下后台刷盘已跟不上写入节奏。
同时观察 aof_last_write_status 是否为 ok，以及 aof_buffer_length 是否长期 > 1MB。这两者叠加出现，基本可以判定 AOF 缓冲区堆积严重，everysec 已经不够用了。
- 若
aof_delayed_fsync > 0且持续上升 → 后台 fsync 跟不上，考虑升级磁盘或降低写入压力 - 若
aof_buffer_length长期 > 2MB → 写入速率远超 fsync 能力，everysec失效风险升高 - 不要依赖
latency doctor的模糊提示，优先盯紧info persistence里的这几个字段
everysec 模式下还能怎么压榨吞吐？
默认 everysec 并不等于“每 1000ms 刷一次”，Redis 实际使用的是一个带抖动的定时器（避免多个实例在同一毫秒触发刷盘造成 I/O 尖峰）。但你可以通过调整内核参数和 Redis 配置协同优化：
- 确保
vm.dirty_ratio和vm.dirty_background_ratio不过低（例如低于 10 / 5），否则内核会提前抢跑刷页，干扰 Redis 自身的fsync节奏 - 禁用
appendfilename所在文件系统的atime更新（挂载选项加noatime），减少无关元数据写入 - 把 AOF 文件放在独立 SSD 分区（非系统盘、非与 RDB 共享的磁盘），避免 I/O 竞争
- 如果使用 Linux 5.1+，可尝试启用
appendfsync everysec+no-appendfsync-on-rewrite yes，避免重写期间fsync被阻塞（但要注意：重写时若崩溃，AOF 可能不完整）
AOF 重写期间写入卡顿？重点检查 auto-aof-rewrite-percentage
很多人以为卡顿是 fsync 引起的，其实更常见原因是 AOF 重写触发太频繁。当 auto-aof-rewrite-percentage 设得太小（比如 50），而业务写入中包含大量 DEL、EXPIRE、HDEL 这类逻辑删除命令时，AOF 文件体积增长缓慢，但重写却高频触发——每次重写都会 fork 子进程、遍历内存、生成新文件，CPU 和 I/O 压力陡增。
建议根据实际 AOF 增长速率动态设置：先用 redis-cli info persistence | grep aof_current_size 和 aof_base_size 观察 1 小时内增长比例，再把 auto-aof-rewrite-percentage 设为该值的 2–3 倍，并配合 auto-aof-rewrite-min-size（如 64mb）避免小文件反复重写。
- 重写期间主线程仍要处理写请求，并追加到旧 AOF 文件，所以卡顿往往表现为
used_memory_peak突增 +instantaneous_ops_per_second下跌 -
bgrewriteaof手动触发后，务必检查aof_rewrite_in_progress是否及时归零，否则说明子进程卡死或磁盘满 - 如果重写耗时超过 30 秒，优先排查磁盘 I/O 负载，而不是调大
percentage
真正影响 AOF 写入性能的，从来不是「开不开」，而是「什么时候刷、刷多少、谁来刷」。很多线上问题，其实只需要改一行 appendfsync，再盯住两个 info persistence 字段，就能定位到根因。磁盘 I/O 是硬约束，所有优化都绕不开物理限制——与其调参调到怀疑人生，不如先确认你的 SSD 是否真的在承担 AOF 写入任务，而不是被日志、监控、容器 overlayfs 一起挤占着。
