高并发下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 的典型表现。
- 现象：TPS 突然从 8000 掉到 2000，
redis-cli info persistence显示aof_delayed_fsync: 12 - 原因：SSD 写放大 + AOF 重写同时进行，IO 调度队列积压
- 验证方式：用
iostat -x 1观察%util是否长期 >90，await是否 >50ms
appendfsync no 的真实代价和适用边界
appendfsync no 不是“不刷盘”，而是把控制权交给操作系统 —— 通常每 30 秒或 page cache 满时批量刷一次。它换来的是写吞吐提升 2–3 倍，但代价是宕机可能丢失最多 30 秒数据。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 能用的前提：业务接受秒级以上数据丢失（例如用户在线状态、实时排行榜、埋点缓存）
- 不能用的场景：账户余额变更、订单创建、支付回调等强一致性操作
- 注意：即使设为
no，AOF 文件仍会增长，需靠auto-aof-rewrite-percentage控制重写频率
重写期间必须关闭 fsync 同步
AOF 重写本身就要读全量数据、序列化、写新文件，IO 压力巨大。若此时还让主线程按 everysec 或 always 刷盘，等于双线程抢同一块磁盘，极易触发超时和连接拒绝。
- 配置项
no-appendfsync-on-rewrite yes的作用：重写开始后，临时忽略appendfsync设置，暂停所有 fsync - 副作用：重写期间新写入命令只进缓冲区，不落盘；若此时崩溃，这部分数据全丢
- 必须搭配：确保
auto-aof-rewrite-min-size不设过低（建议 ≥64mb），避免频繁重写
混合持久化不是银弹，要配对启用
aof-use-rdb-preamble yes 只有在 AOF 重写时才生效，它让重写过程先 dump 一个 RDB 快照，再追加增量命令。这能大幅缩短恢复时间，但前提是 RDB 压缩已开启且 AOF 本身没被禁用。
- 常见错误：开了
aof-use-rdb-preamble yes却没开appendonly yes，实际无效 - 性能影响：RDB 部分是子进程完成，不影响主线程；但增量追加仍走 AOF 流程，刷盘策略依然生效
- 真正起效条件：必须配合
appendfsync no或everysec，否则 RDB 快照优势被 AOF 刷盘拖累
刷盘策略调优不是改一个参数就完事 —— 它和重写机制、磁盘类型、业务容忍度深度耦合。最容易被忽略的是 aof_delayed_fsync 这个指标，它不报警、不报错，但数值 >0 就说明主线程已在等待，此时再压高并发只会放大问题。
