卡点不在fsync本身，而在aof_buf写满后主线程被迫同步等待；默认8KB缓冲区在QPS超5k、命令平均超100字节时易打满，触发阻塞导致SET延迟飙升至毫秒级。
appendfsync everysec 为什么还会卡写入？
卡点不在 fsync 本身，而在主线程的 aof_buf 写满后被迫同步等待。默认 8KB 缓冲区在 QPS 超过 5k、命令平均长度超 100 字节时极易打满，触发阻塞——此时 SET 延迟会从微秒级跳到毫秒甚至百毫秒级。
验证方式很简单：redis-cli info persistence 查看两个关键字段：
-
aof_buffer_length长期 > 1MB，说明缓冲区持续积压 -
aof_delayed_fsync每分钟增长上百次，代表主线程频繁被挂起等刷盘
这两个指标同时升高，基本可判定 everysec 已经跟不上写入节奏，不是策略选错了，是缓冲和 I/O 协同没调好。
不改源码怎么缓解 aof_buf 压力？
Redis 不提供运行时调整 aof_buf 大小的配置项，硬改要动 src/aof.c 里的 AOF_BUFFER_INIT_SIZE 并重编译——生产环境不现实。更可行的是用重写机制间接“清空”压力：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 把
auto-aof-rewrite-percentage从默认 100 降到 50～70，让重写更早触发，避免 AOF 文件膨胀后写放大 - 把
auto-aof-rewrite-min-size提高到 256mb 或更高（比如日增 2GB 的业务），减少重写频次，降低子进程调度抖动 - 务必开启
no-appendfsync-on-rewrite yes：重写期间跳过fsync，否则主线程写新命令 + 子进程刷旧文件，双重 I/O 压力直接雪崩
everysec 模式下哪些系统级配置必须调？
Linux 内核和文件系统不配合，everysec 就是纸面参数。实测中这几个点漏掉一个，吞吐就掉 30% 以上：
- 挂载选项加
noatime，禁用访问时间更新，减少元数据写入干扰 - 调高内核脏页阈值：
vm.dirty_ratio=10、vm.dirty_background_ratio=5，避免内核抢在 Redis 之前刷页，打乱everysec的节奏 -
appendfilename必须放在独立 SSD 分区，不能和系统盘、RDB 文件混用；NVMe 更佳，随机写 IOPS 差距可达 50 倍
这些不是“建议”，而是 everysec 能稳定跑出标称性能的前提条件。
混合持久化（aof-use-rdb-preamble）到底省在哪？
开启 aof-use-rdb-preamble yes 后，AOF 重写不再纯文本追加，而是先写一段 RDB 格式的二进制快照头，再接增量命令。它真正节省的不是磁盘空间，而是两个关键环节：
- 重写耗时下降 40%～60%：RDB 序列化比逐条生成 AOF 命令快得多，尤其对大 hash/list
- 重启加载快 3～5 倍：RDB 部分直接 mmap 加载，不用逐行解析协议和执行命令
- 重写期间
aof_buffer_length增长变慢：因为快照部分覆盖了大量旧状态，增量命令自然减少
这个配置只在 Redis 4.0+ 有效，且必须配合 appendfsync everysec 和 no-appendfsync-on-rewrite yes 才能发挥最大效果。单独开它，其他地方没调，收益几乎感知不到。
