everysec是生产默认安全线：主线程不阻塞、吞吐损失<5%、最多丢1秒数据；always适合金融账务但QPS降40%–70%；no依赖OS不可控，可能丢数十秒数据。

Redis AOF 频繁刷盘策略的核心取舍点，不在“要不要快”，而在“谁来承担延迟与丢失风险”——主线程不能卡，数据不能多丢，磁盘和系统也不能被拖垮。

everysec 是生产集群的默认安全线

这是最常用也最平衡的配置：命令写入 AOF 缓冲区（aof_buf）后立即返回客户端，后台由独立线程每秒执行一次 fsync。它在性能和可靠性之间划出清晰边界：

• 写吞吐基本不受影响，QPS 损失通常低于 5%
• 宕机最多丢失 1 秒内未刷盘的命令，对多数业务可接受
• 避免了 always 带来的高延迟毛刺和网络分区时主从 AOF 不一致问题
• 比 no 更可控——操作系统延迟不可预测，极端情况下可能积压 30 秒，风险陡增

always 只适合极少数强一致性场景

每次写都 fsync 到磁盘，理论上零数据丢失，但代价明显：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 写入吞吐下降 40%–70%，尤其在机械盘或低 IOPS 云盘上更严重
• 主线程等待磁盘响应，P99 延迟跳变频繁，不适合高并发读写混合场景
• 在网络不稳定或主从同步压力大时，容易触发 AOF 同步中断或加载失败
• 金融类核心账务系统若真要用，必须搭配 SSD + 内核调优（如 io scheduler 设为 deadline）

no 策略需谨慎评估系统可靠性

依赖操作系统缓冲区自动刷盘，看似轻量，实则把风险转嫁给 OS 和硬件：

• 断电或内核崩溃时，可能丢失数十秒甚至全部未落盘命令
• Linux 默认 dirty_ratio/dirty_background_ratio 设置下，缓存积压可能引发突发 IO 尖峰
• 仅建议用于开发测试、缓存降级层或允许容忍短时数据不一致的中间状态存储
• 若启用，务必配合监控 aof_last_write_status 和 aof_pending_bio_fsync 指标，及时发现刷盘滞后

配合重写机制才能真正稳住 AOF 文件增长

刷盘策略只是“怎么写”，而 auto-aof-rewrite-min-size + auto-aof-rewrite-percentage 才决定“什么时候压缩”。两者必须协同：

• 建议设 auto-aof-rewrite-percentage 100（AOF 体积翻倍即触发），auto-aof-rewrite-min-size 64mb，避免小文件频繁重写
• 重写期间子进程会 fork + 重放命令，CPU 和内存压力上升，应避开业务高峰时段
• 重写失败或中断会导致 aof_current_size 持续膨胀，需设置 aof-rewrite-incremental-fsync yes 减少单次刷盘量
• 检查 aof_base_size 是否异常小——说明上次重写没成功，可能已积累大量冗余命令