appendfsync决定崩溃恢复边界：always每命令同步，最多丢0条；everysec每秒同步，最多丢1秒数据；no依赖系统，可能丢数十秒。fsync失败会导致静默数据丢失，需监控告警。
appendfsync 配置直接决定刷盘一致性边界
Redis 不提供“强一致刷盘”这种模糊概念，它只按 appendfsync 的取值严格执行三种确定性行为。所谓“一致性”，实际是“崩溃后能恢复到哪一时刻的数据”，完全由该配置定义：
-
always：每条写命令调用write()后立刻跟fsync()，主线程阻塞直到落盘完成。崩溃最多丢失当前事件循环中未执行完的命令（通常为 0 条）。 -
everysec：命令写入 AOF 缓冲区 →write()到内核 page cache → 后台线程每秒一次fsync()。崩溃最多丢失最近 1 秒内的写操作。 -
no：仅执行write()，后续全交给操作系统。Linux 默认约 30 秒 flush 一次，崩溃可能丢失数十秒数据。
没有中间态，也不存在“部分刷盘成功”的情况 —— fsync() 要么成功（数据已落盘），要么失败（Redis 记录日志并继续运行，但此时 AOF 文件已处于不一致状态，需人工介入）。
后台 fsync 线程不会导致 AOF 文件内容错乱
everysec 模式下，fsync() 由独立后台线程执行，但 AOF 文件内容不会因此出现命令截断或顺序错乱。原因在于：
- 主线程只负责把完整命令追加到
server.aof_buf（sds 结构），追加是原子的； - 后台线程每次
fsync()前，会先调用write()把整个缓冲区内容刷到文件末尾，再同步； - Redis 不做 partial write 校验，但 Linux
write()对普通文件保证“要么全写，要么返回错误”，不会写一半。
所以即使后台线程因磁盘繁忙被阻塞，AOF 文件始终是合法的、可重放的命令序列 —— 只是最新一部分命令还没同步到磁盘而已。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
AOF 重写期间仍能保持崩溃可恢复性
触发 BGREWRITEAOF 时，主进程一边生成新 AOF 文件，一边继续接收写请求。新请求会同时写入旧 AOF 缓冲区和一个专门的 aof_rewrite_buffer。这保证了：
- 旧 AOF 文件始终可单独用于恢复（哪怕重写中途失败）；
- 新 AOF 文件生成完毕后，Redis 用原子 rename 替换旧文件，并将
aof_rewrite_buffer中积压的命令追加进去； - 整个过程无需锁住主线程，也不影响
appendfsync对当前写流量的刷盘策略。
也就是说，AOF 重写本身不改变刷盘一致性模型，它只是优化文件体积，不是刷盘动作本身。
容易被忽略的 fsync 失败场景
真正破坏 AOF 一致性的，不是配置选错，而是 fsync() 系统调用失败却未被及时发现：
- 磁盘满、I/O 错误、文件系统只读等都会导致
fsync()返回 -1； - Redis 默认记录 ERROR 日志但继续运行，此时 AOF 文件虽存在，但最后几次
write()并未真正落盘； - 如果紧接着发生崩溃，恢复时会从上次成功
fsync()的位置开始重放，造成数据静默丢失。
生产环境必须监控 Redis 日志中的 Failed to fsync the AOF file，并配置告警。仅靠 appendfsync everysec 不等于“安全”，还得确保磁盘和文件系统可靠。
