appendfsync 是什么
appendfsync 决定 AOF 缓冲里的数据什么时候真正落到磁盘，是 AOF 在「性能」与「丢失窗口」之间的总开关。它作用于「缓冲写入文件之后」的那一步，即调用 fsync 把操作系统页缓存刷到物理介质。三个取值代表三档取舍：always 每条命令后都刷、everysec 每秒刷一次、no 完全交给操作系统决定。默认值 everysec 是绝大多数生产环境的选择。
基本信息
| 默认值 | everysec |
|---|---|
| 取值 | always / everysec / no |
| 作用点 | aof_buf 写入文件后的 fsync 时机，不改变命令追加顺序 |
| 修改方式 | CONFIG SET appendfsync everysec，需 CONFIG REWRITE 持久化 |
| 相关风险 | 磁盘抖动时 everysec 可能退化为最长约 2 秒一次 |
典型使用场景
- 绝大多数业务用 everysec：后台线程刷盘不阻塞主线程，丢失窗口可控在 1 秒左右
- 账务、订单核对等零丢失要求场景评估 always，前提是压测确认吞吐与延迟能满足业务指标
- 开发与测试环境可用 no，追求写入速度而数据可随时重建
- 批量导入历史数据时临时放宽到 everysec 或 no，导入完成后再改回严格档位
- 磁盘写入延迟不稳定时，通过监控 aof 相关指标判断是否需要升级到更高 IOPS 的介质
查看与调整
查看与调整
redis-cli CONFIG GET appendfsync # 默认 everysec
redis-cli CONFIG SET appendfsync always # 临时严格模式，注意吞吐下降
redis-cli CONFIG REWRITE # 让改动写回配置文件
redis-cli INFO persistence | grep -E 'aof_last_write_status|aof_current_size'
iostat -x 1 3 # 观察磁盘利用率与 fsync 相关延迟
redis-cli INFO stats | grep -E 'aof_' # 部分版本提供重写与刷盘统计三档对比
| 取值 | 刷盘时机 | 丢失窗口 | 性能代价 |
|---|---|---|---|
| always | 每条写命令执行后同步 fsync | 接近零，仍取决于磁盘是否确实确认 | 吞吐显著下降，延迟受磁盘抖动影响 |
| everysec | 后台线程每秒 fsync 一次 | 约 1 秒 | 通用默认，主线程几乎无感 |
| no | 由操作系统决定何时刷页缓存 | 通常数十秒甚至更久 | 写入最快，失控风险最大 |
everysec 之所以成为默认：fsync 由后台线程执行，主线程只负责把数据写进 AOF 缓冲并交给内核，因此业务不会因为磁盘慢而被拖住。当后台 fsync 超过预期时间仍未完成时，Redis 会推迟下一次 fsync，这段时间的数据都在内核页缓存里，这也是「断电可能丢约 1 秒」的由来。
把 everysec 理解成「不丢数据」是最常见的误判：断电、宿主机崩溃、内核 panic 都会让页缓存里尚未 fsync 的内容消失。需要零丢失只能选 always，并接受性能代价，同时确认磁盘本身不会谎报写入完成。