appendfsync everysec 卡住的根本原因是磁盘 i/o 饱和导致 fsync 后台线程阻塞或积压，表现为 aof_delayed_fsync 持续大于 0、redis 延迟突增及日志提示异步 fsync 耗时过长。

为什么 appendfsync everysec 还会卡住？

因为 everysec 并不等于“每秒稳稳 fsync 一次”——它依赖后台线程，而该线程可能被阻塞或积压。常见现象是：Redis 响应延迟突增、aof_delayed_fsync 指标持续大于 0、日志里反复出现 Asynchronous AOF fsync is taking too long。

• 根本原因不是配置错，而是磁盘 I/O 已饱和：fsync 调用排队，后台线程无法及时完成落盘
• 触发条件常被忽略：AOF 重写（bgrewriteaof）期间，主线程仍在追加写入，两个写流争抢磁盘带宽
• 更隐蔽的坑：某些云盘（如低配 EBS 或 NFS 卷）在突发写入时延迟飙升，但 df -h 看不出异常

怎么确认磁盘真的扛不住了？

别只看 df -h，要盯真实 IO 延迟和 fsync 积压。直接查 Redis 自身指标最准：

• 运行 redis-cli info persistence | grep -E "aof_delayed_fsync|aof_last_fsync_time_sec"：若 aof_delayed_fsync > 0 且持续增长，说明 fsync 已开始排队
• 检查系统级延迟：iostat -x 1 关注 %util（接近 100% 即饱和）和 await（单次 IO 平均等待毫秒数，>20ms 就危险）
• 验证磁盘是否“假快”：echo 1 > /proc/sys/vm/drop_caches && time dd if=/dev/zero of=/path/to/redis/data/test bs=4k count=10000 oflag=direct —— 绕过缓存测裸盘写速，低于 5MB/s 基本可判为瓶颈

no-appendfsync-on-rewrite yes 真的安全吗？

它能缓解卡顿，但代价是 AOF 文件在重写期间不落盘——如果此时 Redis 崩溃，最近一秒（everysec）+ 重写期间所有新写入都会丢失。

Redis Skill - 高性能缓存管理

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

下载

• 适用场景：业务能容忍短时间双倍数据丢失（比如非核心计数器），且重写频率不高（auto-aof-rewrite-percentage 设得够大）
• 风险点：一旦开启，必须确保 appendfsync 不是 always（否则该配置无效），且要监控 aof_rewrite_in_progress 避免长时间重写
• 实操建议：先调大重写触发阈值，例如 config set auto-aof-rewrite-percentage 200 + config set auto-aof-rewrite-min-size 2gb，再开此开关

换 SSD 之前，先检查这三处权限和挂载参数

很多团队上了 NVMe 盘仍卡顿，最后发现是文件系统没对齐或容器权限锁死了写入路径。

• 确认挂载选项：mount | grep redis，理想是 noatime,data=writeback；避免 sync 或 barrier=1 这类强一致性参数
• K8s 场景重点查：kubectl exec -it <pod> -- ls -ld /data</pod> 和 touch /data/test，若报 Permission denied，大概率是 securityContext.fsGroup 未匹配 Redis 用户 UID（通常为 999 或 1001）
• Linux 内核缓冲区也要调：sysctl -w vm.dirty_ratio=10 和 vm.dirty_background_ratio=5，防止脏页堆积倒逼 Redis 主动阻塞

磁盘 IO 瓶颈最麻烦的地方不在“慢”，而在“不可预测”：同一套配置，上周跑得好好的，这周突然卡住，往往是因为磁盘队列悄悄堆满了，而所有监控都还显示“一切正常”。盯住 aof_delayed_fsync 和 iostat 的 await，比调参更能提前发现问题。