卡点不在fsync本身，而在aof_buf写满后主线程阻塞等待刷盘；默认8KB缓冲区在高吞吐下易打满，需通过调大缓冲区（源码重编译）或优化重写策略（auto-aof-rewrite-percentage、aof-rewrite-min-size配合no-appendfsync-on-rewrite）缓解积压。
为什么 appendfsync everysec 还会卡主线程？
卡点不在 fsync 本身，而在 aof_buf 写满后主线程阻塞等待刷盘。Redis 主线程每次执行命令都得把协议数据追加进这个内存缓冲区，一旦满了又没被后台线程及时消费（比如磁盘忙、aof_delayed_fsync > 0），就会同步等待——此时 SET 延迟直接跳到毫秒级。
常见信号：
-
INFO persistence中aof_buffer_length长期 > 1MB - 日志反复出现
Asynchronous AOF fsync is taking too long -
aof_delayed_fsync或aof_pending_bio_fsync非零
默认 aof_buf 只有 8KB，对 QPS 5k+ 的小命令场景极易打满。它不是运行时可配参数，改不了配置文件，必须改源码重编译（src/aof.c 中的 AOF_BUFFER_INIT_SIZE）；但更现实的做法是压住缓冲区积压节奏。
如何用重写策略缓解 aof_buf 压力？
重写不是“清空缓冲区”，而是生成新 AOF 文件并替换旧文件，过程中会释放旧文件占用空间、减少后续 write() 的系统调用开销，间接降低 aof_buf 持续高位的风险。
关键可调参数只有两个，且需配合使用：
-
auto-aof-rewrite-percentage：默认 100，表示当前 AOF 比上次重写后增大一倍才触发。若业务增长快（如每小时增 1GB），设为 50 或 30 能更早启动重写 -
aof-rewrite-min-size：默认 64mb，避免小文件频繁重写。若 AOF 日常达数 GB，可提到 256mb 或 1gb，让重写更集中、减少子进程调度抖动 - 必须搭配
no-appendfsync-on-rewrite yes：重写期间跳过fsync，否则磁盘 I/O 竞争会让aof_buf积压雪上加霜
注意：CONFIG SET 修改不持久化，重启即丢；务必写进 redis.conf 并 reload 或重启生效。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
混合持久化（aof-use-rdb-preamble）到底起不起作用？
它不是独立开关，而是 AOF 的一种格式变体——只在 appendonly yes 且成功执行过 BGREWRITEAOF 后才生效。很多用户配了 aof-use-rdb-preamble yes 却发现启动仍加载 dump.rdb，就是因为没满足这两个前提。
验证是否真启用混合格式：
- 用
head -c 16 appendonly.aof | hexdump -C查前 16 字节 - 看到
52 45 44 49 53 30 30 31 31（即REDIS0011）→ 是混合格式 - 看到
2a 33 0d 0a ...（即*3\r\n开头）→ 还是纯 AOF，重写没成功或重写时aof-use-rdb-preamble实际为no
混合格式真正价值在于重启速度：RDB preamble 部分越新，AOF 尾部越短，恢复越快。所以别光调重写阈值，大写入前手动 BGREWRITEAOF 更可控。
磁盘和内核层面哪些细节容易被忽略？
再好的 Redis 配置也扛不住底层 I/O 拖累。实测中，以下三点常成为隐形瓶颈：
-
iostat -x 1看%util是否长期 > 80%、await是否 > 10ms——这说明磁盘已饱和，调缓冲区或重写策略都没用 -
vm.dirty_ratio和vm.dirty_background_ratio默认值（30/10）对 SSD 不友好，建议调成10/5，让内核更积极刷脏页，减少write()阻塞 - 挂载参数不用
noatime,data=writeback，会导致每次write()都触发元数据更新，白白增加 I/O 次数
AOF 性能从来不是单点问题：缓冲区大小、重写节奏、fsync 策略、磁盘吞吐、内核刷页行为，全链路都要对齐。某个环节松动，其他优化就打折扣。
