appendfsync always不能保证单条写不丢，因其仅控制fsync调用时机，无法规避内核page cache延迟、硬盘写缓存未禁用、进程在write后fsync前崩溃、文件系统（如ext4 barrier=0）及硬件故障等多重风险，实际最多丢失1条命令。
appendfsync always 为什么不能保证单条写不丢
因为 appendfsync always 只控制 AOF 文件的 fsync 调用时机，不控制内核缓冲区刷盘完成与否，也不覆盖 Redis 进程崩溃、磁盘硬件故障等非软件层风险。
内核 write() 成功 ≠ 数据落盘
Redis 执行 write() 将命令追加到 AOF 文件后，数据先进入内核页缓存（page cache），appendfsync always 会立即调用 fsync() 强制刷盘——但这个调用本身可能失败，或被内核静默延迟（尤其在某些 ext4 + barrier=0 或 XFS 配置下）。更关键的是：fsync() 返回成功，只表示“内核已将数据提交给磁盘驱动”，不代表磁盘控制器已真正写入闪存/磁盘介质。消费级 SSD、部分企业级 NVMe 卡在断电瞬间仍可能丢失最后一批未落盘的写请求。
进程崩溃发生在 fsync 之前
虽然 appendfsync always 在每次写命令后触发 fsync()，但整个流程是串行的：写入 AOF 缓冲 → write() → fsync()。如果 Redis 进程在 write() 完成后、fsync() 开始前崩溃（例如因 OOM Killer 杀死、SIGKILL 强制终止），AOF 文件只追加了命令但未刷盘，重启时该命令不可见。
硬件与文件系统层面的隐性失效
以下情况会让 appendfsync always 失效，且无日志报错：
- 磁盘开启 write cache 且未配 UPS：断电时缓存中未写入的数据永久丢失
- ext4 挂载参数含
data=writeback：日志和数据不同步，fsync()不保证数据落盘 - RAID 卡电池失效或 write-back cache 关闭失败：实际退化为 write-through 模式，性能下降但未报警
- 使用 overlayfs 或某些容器卷驱动：
fsync()被拦截或降级，无法穿透到底层物理设备
真正能缩小丢失窗口的，不是单靠 appendfsync always，而是配合 min-slaves-to-write + min-slaves-max-lag 把写操作卡在主节点入口，再用外部 WAL（如 Kafka）兜底关键事务——这些细节常被配置文档忽略，却直接决定“单条不丢”是否成立。
