如果说 RDB 是拍快照，AOF 就是记流水。每个写命令追加到日志里，重启时再按日志重放，就能恢复数据。
问题在于：命令写到 AOF buffer、写到操作系统 page cache、真正 fsync 到磁盘，是三个不同层次。你选择的 appendfsync 策略，决定了性能和数据安全边界。
先把机制边界说清楚
这一篇讨论 AOF 写入链路和刷盘策略，不把 AOF 描述成绝对不丢数据。只要不是每条命令同步 fsync，就一定存在窗口。
整体路径
上面这张图先把主线铺开：buffer、page cache、disk 之间隔着明确的数据窗口。读 Redis 这类系统，最重要的是别只停在命令接口，要继续追问它在内存里是什么形状、在主线程上走多远、失败时会留下什么状态。
底层机制
appendfsync always最安全也最慢，每条写命令都可能等待磁盘。appendfsync everysec是常见默认折中，通常最多丢约一秒窗口内的数据。appendfsync no把刷盘交给操作系统，性能好但丢失窗口更不可控。- 磁盘 IO 抖动会让 AOF 刷盘延迟传导到 Redis 延迟曲线。
这些机制放在一起看，就能把「这个命令能不能用」改成「这个命令在当前数据规模下还便不便宜」。Redis 的很多坑，不是命令本身错了，而是数据规模和访问方式已经越过了它的舒适区。
取舍与边界
AOF 不是“开了就安全”，而是你愿意用多少延迟换多少持久性。业务要先定义可接受的数据窗口。
典型问题：用机制化例子排查
- 核心状态优先 everysec，并监控
aof_delayed_fsync。 - 磁盘延迟、空间占用和 rewrite 进度要进入 Redis 监控面板。
- AOF 文件增长过快时，不要只调 rewrite 阈值，还要看写入模型是否异常。
- 关键数据仍要有上游数据库或补偿链路，Redis 持久化不是最终审计账本。
收束：一句判断
AOF 的本质，是在延迟和丢失窗口之间签一份明确合同。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
如果你想继续跟完这套「图解 Redis」，欢迎关注公众号 「十三Tech」。后续会继续按数据结构、底层机制、持久化、高可用和实战排查这条线更新。
