在高并发写入场景下如何优化Redis的日志刷盘策略？

高并发下appendfsync no最有效，但须配no-appendfsync-on-rewrite yes与监控；everysec因后台fsync阻塞超2秒会致主线程等待，引发TPS骤降与aof_delayed_fsync升高。

直接结论：高并发写入时，appendfsync no 是最有效的日志刷盘策略调整点，但必须配合 no-appendfsync-on-rewrite yes 和监控手段，否则容易在重写期间触发磁盘 IO 雪崩。

为什么 everysec 在高并发下反而会卡住主线程

everysec 看似平衡，但在磁盘负载高时，后台 fsync 线程会被阻塞，而 Redis 主线程会轮询检查该线程是否完成 —— 一旦延迟超过 2 秒，主线程就会主动等待，导致写命令堆积、响应变慢。这不是理论风险，而是 aof_delayed_fsync 指标持续 >0 的典型表现。

1. 现象：TPS 突然从 8000 掉到 2000，redis-cli info persistence 显示 aof_delayed_fsync: 12
2. 原因：SSD 写放大 + AOF 重写同时进行，IO 调度队列积压
3. 验证方式：用 iostat -x 1 观察 %util 是否长期 >90，await 是否 >50ms

appendfsync no 的真实代价和适用边界

appendfsync no 不是“不刷盘”，而是把控制权交给操作系统 —— 通常每 30 秒或 page cache 满时批量刷一次。它换来的是写吞吐提升 2–3 倍，但代价是宕机可能丢失最多 30 秒数据。

1. 能用的前提：业务接受秒级以上数据丢失（例如用户在线状态、实时排行榜、埋点缓存）
2. 不能用的场景：账户余额变更、订单创建、支付回调等强一致性操作
3. 注意：即使设为 no，AOF 文件仍会增长，需靠 auto-aof-rewrite-percentage 控制重写频率

重写期间必须关闭 fsync 同步

AOF 重写本身就要读全量数据、序列化、写新文件，IO 压力巨大。若此时还让主线程按 everysec 或 always 刷盘，等于双线程抢同一块磁盘，极易触发超时和连接拒绝。

1. 配置项 no-appendfsync-on-rewrite yes 的作用：重写开始后，临时忽略 appendfsync 设置，暂停所有 fsync
2. 副作用：重写期间新写入命令只进缓冲区，不落盘；若此时崩溃，这部分数据全丢
3. 必须搭配：确保 auto-aof-rewrite-min-size 不设过低（建议 ≥64mb），避免频繁重写

混合持久化不是银弹，要配对启用

aof-use-rdb-preamble yes 只有在 AOF 重写时才生效，它让重写过程先 dump 一个 RDB 快照，再追加增量命令。这能大幅缩短恢复时间，但前提是 RDB 压缩已开启且 AOF 本身没被禁用。

1. 常见错误：开了 aof-use-rdb-preamble yes 却没开 appendonly yes，实际无效
2. 性能影响：RDB 部分是子进程完成，不影响主线程；但增量追加仍走 AOF 流程，刷盘策略依然生效
3. 真正起效条件：必须配合 appendfsync no 或 everysec，否则 RDB 快照优势被 AOF 刷盘拖累

刷盘策略调优不是改一个参数就完事 —— 它和重写机制、磁盘类型、业务容忍度深度耦合。最容易被忽略的是 aof_delayed_fsync 这个指标，它不报警、不报错，但数值 >0 就说明主线程已在等待，此时再压高并发只会放大问题。