Redis 的 AOF 刷盘和重写有什么区别？

AOF 记录恢复数据所需的写操作，刷盘决定日志何时达到持久化要求，重写则缩减历史冗余。刷盘解决可靠性与延迟取舍，重写解决文件体积与恢复成本。 二者不能混为一个过程。

appendfsync 怎么选择？#

写入用户态缓冲、通过 write 进入 OS 缓存、通过 fsync 等同步到底层存储是不同阶段。everysec 常被简记为可能丢一秒数据，但磁盘阻塞和调度会影响实际行为，不能把它当严格的一秒上限。即使 always，也依赖设备和系统正确兑现持久化。

同一个计数器执行一百万次 INCR，恢复最终状态并不一定要重复一百万次操作。重写根据当前数据集生成更紧凑的恢复表示，同时保留重写期间的新修改；它不是简单去重旧文件中的文本行，因为命令可能存在依赖关系。

Redis 7.0 起采用多文件 AOF 方案，由基础文件、增量文件及 manifest 管理。启用相应配置时，基础部分可以采用 RDB 格式，也就是常说的混合持久化。旧版本单文件重写的缓冲与文件切换描述不能直接套到所有新版本上。

后台重写也可能 fork，因此要考虑 COW、磁盘空间、同步延迟与写入峰值。恢复时要使用完整一致的 AOF 文件集合和 manifest，不能随便挑一个增量文件复制走。

正常设计会把期间的增量纳入最终持久化文件集合。故障安全仍受刷盘策略和文件管理影响，不能只因为“后台重写”就断言零丢失。

启用 AOF 时通常优先用 AOF 路径恢复，因为它往往更完整；混合格式中的 RDB 基础部分也属于 AOF 恢复集合。

应先保留备份，再使用对应版本检查工具和恢复流程评估。截断可能丢数据，多文件 AOF 还需检查 manifest，不能凭文本编辑猜测。

需要视可用性要求决定。AOF服务于本节点恢复，副本服务于其他节点接管；本机磁盘持久化并不自动解决机器整体失效。