AOF everysec最多丢2秒数据，因fsync依赖事件循环空闲触发，主线程阻塞会导致调度延迟，最坏情况下两次fsync间隔接近2秒。
为什么AOF everysec 会丢最多2秒数据
因为Redis的AOF everysec 模式下，写命令先追加到内存缓冲区（aof_buf），再由后台线程每秒调用一次 fsync 刷盘。但这个“每秒”不是严格定时器——它依赖事件循环空闲时触发，若主线程持续忙碌（比如大key删除、复杂Lua脚本），fsync 可能被延迟；更关键的是，如果在上一次 fsync 完成后、下一次开始前这整段时间内进程崩溃，所有尚未落盘的缓冲区数据就丢了。
- 最坏延迟 = 上次
fsync完成时刻 → 下次fsync开始时刻，理论最大接近2秒（例如上次在0.9s完成，下次因阻塞拖到2.8s才启动） - 这不是bug，是设计取舍：用可控延迟换性能，
always虽不丢但吞吐暴跌，no则完全交由OS决定，风险更高 - 注意：Linux的
fsync在某些存储设备（如部分NVMe或启用了写缓存的RAID卡）上可能返回过快，实际数据仍在设备缓存中，此时“2秒”只是OS层面的保证，物理落盘仍可能滞后
如何确认当前实例是否真正在承受fsync延迟
不能只看配置是 everysec，得验证实际行为。Redis本身不直接暴露fsync耗时，但可通过两个指标交叉判断：
- 观察
INFO persistence中的aof_delayed_fsync：该计数器每次因主线程忙而跳过本次fsync时+1，值持续增长说明调度已受挤压 - 检查
aof_last_fsync和aof_current_rewrite_time_sec的差值（需排除rewrite干扰），若长期 > 1.5s，基本可判定存在延迟 - 更准的方式是用
strace -p $(pidof redis-server) -e trace=fsync抓系统调用，看两次fsync间隔和单次耗时（注意别在生产高频实例上长时运行）
哪些操作会让fsync更容易超时
任何让主线程长时间无法进入事件循环的操作，都会挤压 fsync 的执行窗口。典型场景包括：
- 同步删除大key（
DEL一个几GB的hash）—— Redis 6.0+ 默认异步，但若配置了lazyfree-lazy-user-del no或使用旧版本，就会阻塞 - 执行耗时Lua脚本（尤其含循环或大量
redis.call()）—— 脚本全程在主线程运行，期间不处理任何其他事件 - 主从全量同步时的RDB生成（
save进程虽是子进程，但fork瞬间会触发写时复制，造成主线程卡顿，间接影响后续fsync调度） - 开启
activedefrag且内存碎片率高时，后台整理也会周期性占用CPU时间片
想降低丢数据风险，但又不想切always，有什么折中办法
没有银弹，但可以分层控制风险面：
- 把写敏感业务拆到单独Redis实例，禁用AOF，改用RDB + 主从复制（靠
repl-backlog缓冲和从库实时同步来保可用性） - 对必须开AOF的实例，确保磁盘I/O能力冗余：用XFS文件系统（比ext4更稳）、关闭磁盘写缓存（
hdparm -W0 /dev/sdX）、避免与日志/数据库混用同一块盘 - 监控
aof_delayed_fsync增速，结合业务峰值设置告警（例如5分钟内增长 > 10次，说明fsync已开始失守） - 接受“2秒”是理论上限，实际线上多数情况丢失在毫秒级——真正危险的是连续多次延迟叠加，所以重点盯住延迟是否常态化，而不是纠结单次数字
真正难处理的，是那些既要求低延迟写入、又要求强持久化的场景：fsync本身不可绕过，而硬件和内核的不确定性永远存在。
