everysec 模式下主线程不阻塞，而是将 fsync 请求提交给后台线程异步执行；实际落盘延迟受 I/O 负载和内核参数影响，可能数秒甚至失败，连续两次失败则降级为 no；监控 aof_pending_bio_fsync 和 aof_delayed_fsync 可判断磁盘 I/O 是否瓶颈。
everysec 不等于“每秒落盘”，主线程只提交请求
Redis 的 appendfsync everysec 并不是主线程每秒调用一次 fsync()，而是每次写入后立即将 fsync 请求提交给后台线程，由内核的 writeback 线程异步执行。这意味着：
- 主线程从不阻塞，吞吐不受磁盘延迟直接影响
- 实际落盘时间取决于 I/O 负载、脏页比例（vm.dirty_ratio）、内核调度，可能延迟数秒甚至失败
- 如果连续两次后台 fsync 失败（如 EAGAIN 或超时），Redis 会自动降级为 no 模式，直到下次重试成功
监控关键指标：aof_pending_bio_fsync（待执行的后台 fsync 数）和 aof_delayed_fsync（因 I/O 压力被推迟的次数）。若前者长期 > 10 且持续 30 秒以上，说明后台线程已跟不上——这不是配置问题，是磁盘 I/O 已成瓶颈。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
always 模式下性能断崖下跌的真实原因
appendfsync always 是同步阻塞式 fsync：每次写命令后，主线程必须等 fsync() 返回成功才响应客户端。它的问题不在“多了一次系统调用”，而在于：
- fsync() 会触发强制刷盘 + 等待设备确认，受磁盘随机 IOPS 限制（尤其机械盘或高负载 SSD）
- QPS 超过磁盘能承受的 fsync 频率（通常 它只适合极低吞吐、强一致性刚需场景（如单点金融记账），且必须搭配专用低延迟磁盘与隔离 I/O 路径。普通业务服务器上启用 always，往往比关 AOF 更容易拖垮服务。
everysec 失效时别硬扛，该切 no 就切
当 aof_pending_bio_fsync 持续高位、aof_delayed_fsync 单秒突增超 1000，说明 everysec 已退化为“伪异步”——后台线程卡住，AOF 缓冲区持续堆积，数据丢失风险反而高于 no 模式。此时：
- 不要调高 vm.dirty_ratio 试图“缓解”，这只会让内核更晚刷脏页，加剧 fsync 延迟
- 不要迷信“折中”，everysec 在 I/O 瓶颈下既没性能也没可靠性
- 直接切到 appendfsync no，配合更激进的监控（如 aof_buffer_length 告警），把问题显性化
- 若业务真不能丢数据，应转向架构层冗余（如主从 + 客户端重试 + WAL 外置），而非在单节点 fsync 上死磕
选策略前先看你的磁盘和内核参数
同一份 redis.conf 在不同机器上表现可能天差地别：
- AOF 文件所在磁盘若挂载了 data=writeback（ext4）或禁用 barrier，always 和 everysec 都可能丢数据，白配
- vm.dirty_background_ratio 和 vm.dirty_ratio 默认值（10/20）在 Redis 高写入场景下极易引发 writeback 延迟，建议压到 5/10
- 使用 noatime 是安全的，但 nobarrier 必须谨慎，仅限日志盘完全独立且有 UPS 的环境
- SSD 寿命不是主要瓶颈，但队列深度（nr_requests）和 I/O 调度器（none or mq-deadline）会影响 everysec 的稳定性
everysec 的“平衡”建立在 I/O 可控前提下；一旦磁盘或内核参数失配，它就只是个看起来体面的失效开关。
