应根据业务容忍丢失窗口和磁盘I/O承载力选择：always适合极低吞吐强一致场景，everysec是默认推荐（RPO≈1秒），no适用于纯缓存或高写压且有外部兜底的场景。
选 fsync 策略，核心不是看“要不要落盘”，而是看你的业务能容忍多大窗口的数据丢失，以及当前磁盘 I/O 是否扛得住同步压力。always 并不真正零丢数据，no 也并非完全不能用——关键在匹配场景。
always：只适合极少数强一致刚需场景
每次写命令后，主线程必须等 fsync() 完成才返回响应。它的问题不是“多一次调用”，而是阻塞 + 强制刷盘，直接受限于磁盘随机 IOPS（机械盘通常
更要紧的是，它仍会丢数据：内核 page cache 可能缓存 fsync 请求、硬盘写缓存未禁用、进程被 SIGKILL 杀死在 write 和 fsync 之间——三重断层让“绝对不丢”仅停留在理论层面。
适用场景非常窄：
- 单点金融记账类系统（如流水号生成、余额校验）
- 配套使用低延迟 NVMe 盘 + 独占 I/O 路径 + hdparm -W0 关闭硬盘缓存
- 同时禁用 RDB、关闭 AOF 重写，避免 fork 和 I/O 叠加
everysec：默认推荐，但得会监控和识破失效信号
它不是主线程每秒调用一次 fsync，而是每次写入后立刻把 fsync 请求提交给后台线程异步执行。主线程不阻塞，吞吐稳定，实测单节点 5w+ QPS 下延迟波动在 0.2–0.8ms。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
但实际落盘时间不可控：受 vm.dirty_ratio、I/O 负载、内核 writeback 调度影响，可能延迟数秒；连续两次后台 fsync 失败（如 EAGAIN 或超时），Redis 会自动降级为 no 模式。
务必盯紧两个指标：
- aof_pending_bio_fsync：后台待执行的 fsync 数量，持续 >10 且超 30 秒 → 磁盘已成瓶颈
- aof_delayed_fsync：因 I/O 压力被推迟的次数，单秒突增超 1000 → everysec 已退化为“伪异步”
此时别硬撑，该切 no 就切——继续扛着，AOF 缓冲区堆积，反而比 no 更容易全量丢失。
no：不是放弃持久化，而是把责任移出 Redis
完全交由操作系统决定刷盘时机（通常是 30–60 秒），主线程彻底无 I/O 干扰。但它不等于“不持久”，而是把可靠性保障交给架构层。
适用两类明确场景：
- 纯缓存用途：比如 session 存储，前端有兜底、AOF 仅用于故障后快速重建热 key 分布
- 写压极高且磁盘 util 持续 >90% 的节点：例如每秒 50k+ 小命令写入，everysec 导致 write wait 高企
启用 no 必须同步做两件事：
- 关掉所有 save 配置（避免 bgsave 加剧 fork 和 I/O 压力）
- 在应用层补位：双写 MySQL、投递 Kafka、或搭配 WAL 外置服务——否则宕机就是全量丢失
