aof写入卡顿主因是aof_buf满后主线程阻塞等待刷盘，而非fsync本身；默认8kb缓冲区在高吞吐下易打满，调大需权衡数据丢失与i/o延迟，且须配合重写策略与硬件条件。
为什么 AOF fsync 策略选 everysec 还是会卡写入？
因为卡点不在 fsync 本身，而在 AOF 缓冲区（aof_buf）写满后阻塞主线程等待刷盘。Redis 主线程在每次命令执行后都需将协议数据追加到内存缓冲区，若缓冲区已满且后台子进程（bgrewriteaof 或 fsync 线程）来不及消费，就会触发同步等待——此时 redis-cli 的 SET 命令延迟突然飙升到毫秒级甚至更高。
常见现象：INFO persistence 中 aof_buffer_length 长期 > 1MB，或日志频繁出现 Asynchronous AOF fsync is taking too long 警告。
-
aof_buf默认大小为 8KB，对高吞吐写入（如每秒数万条小命令）极易打满 - 增大缓冲区不是无代价的：内存占用上升，且 crash 后最多丢失缓冲区中未刷盘的数据
- 调整前先确认业务是否允许秒级数据丢失——若要求强持久化（如金融类），
always+ 小缓冲区 + SSD 是更稳妥选择，而非盲目调大
如何安全地调大 aof_buf？
Redis 没有暴露 aof_buf 的运行时配置项，必须通过修改源码重新编译，但实际中更推荐用 auto-aof-rewrite-percentage 和 aof-rewrite-min-size 间接缓解缓冲区压力。
真正可调的缓冲区相关参数只有两个：
-
auto-aof-rewrite-percentage：默认 100，即当前 AOF 文件比上一次重写后增大一倍才触发重写；若设为 50，能更早启动重写，释放旧文件空间并清空部分缓冲积压 -
aof-rewrite-min-size：默认 64mb，避免小文件频繁重写；若业务 AOF 增长快（如日增 2GB），可适当调高（如256mb），让重写更集中、减少子进程调度开销
注意：重写期间仍会持续写入新命令到 aof_buf，所以还需配合 no-appendfsync-on-rewrite yes ——该配置会让 fsync 在重写时跳过，避免双重 I/O 压力，但仅适用于 everysec 模式。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
appendfsync everysec 下，缓冲区大小与磁盘 I/O 的真实关系
缓冲区不是越大越好。当 aof_buf 从 8KB 增至 128KB，单次 write() 系统调用的数据量变大，减少了 syscall 次数，但一旦触发 fsync()，内核需要刷更多脏页，可能延长 fsync 耗时，反而增加主线程等待概率。
实测建议（SSD + Linux 5.4+）：
- 写入 QPS
- 写入 QPS 5k–20k，且命令平均长度 aof_buf 扩容至 32KB（需改
src/aof.c中AOF_BUFFER_INIT_SIZE并重编译） - 写入含大量
LPUSH/RPUSH大列表：优先压缩协议（启用aof-use-rdb-preamble yes），比调缓冲区更有效
验证方式：监控 redis-cli info stats | grep expired_keys 不相关，应盯 aof_delayed_fsync（表示因缓冲满而延迟 fsync 的次数），该值持续 > 0 就说明缓冲区仍是瓶颈。
哪些业务场景根本不该调大缓冲区？
缓冲区扩大会放大数据丢失窗口，尤其在以下场景中风险远大于收益：
- 使用
appendfsync always：此时缓冲区只存命令协议，不涉及 fsync 延迟，调大无意义，还浪费内存 - 部署在机械硬盘（HDD）上：即使缓冲区再大，
fsync仍受限于磁盘寻道，反而因单次刷盘量大导致毛刺更明显 - 开启
aof-rewrite-incremental-fsync yes（默认开启）：重写时已分批刷盘，缓冲区压力本就较低，调大不会改善性能 - 集群中存在跨节点事务型操作（如 Redlock + AOF）：缓冲区延迟会破坏时序假设，导致锁失效或重复消费
最常被忽略的一点：AOF 性能瓶颈往往不在缓冲区，而在 fork() 耗时（尤其是大内存实例）。如果 INFO stats 中 latest_fork_usec 经常 > 100ms，优先优化 vm.overcommit_memory 和 transparent_hugepage，而不是调 aof_buf。
