异步写入海量记录至磁盘的异常处理：文件状态与数据丢失问询

这个问题我之前在处理大规模日志和用户记录持久化的时候碰到过，结合实践经验给你拆解一下：

一、异常发生时的文件状态 #

不同类型的异常，对应的文件状态差异很大：

• 写入阶段的IO/进程异常（比如磁盘满、IO错误、进程崩溃）：
  • 当前正在写入的4MB文件：状态是不完整且大概率损坏的。因为异步写入一般是分块缓冲后写入磁盘，异常发生时最后一批数据可能只写了一半，甚至因为操作系统的页缓存还没刷新，文件内容和你内存里的缓存完全不一致。这种文件基本无法被正常解析。
  • 已经完成写入的历史4MB文件：只要你在文件写入完成后做了强制刷盘（比如Linux下的fsync()，Windows下的FlushFileBuffers()），这些文件就是完整且可靠的，后续异常不会影响它们的内容。
• 文件分割逻辑异常（比如文件名生成失败、大小计算错误）：
  • 可能导致当前文件没有被正确关闭，同样会出现内容截断的情况；如果是在新旧文件切换时出错，还可能出现部分记录重复写入或者漏写的问题，甚至生成无效的空文件。

二、数据丢失的可能性 #

答案是会存在数据丢失风险，主要集中在这几个场景：

• 内存缓冲区中的记录：异步写入通常会用内存缓冲区暂存待写数据，如果异常发生时这些数据还没被刷到磁盘，就会直接丢失。
• 正在写入的单条记录：如果异常恰好发生在某条记录的写入过程中，这条记录可能只被写入了一部分，既无法被正确读取，也等同于丢失了完整的记录。
• 未确认的接收记录：如果你的程序没有做记录级别的持久化确认，比如接收记录后没有先写入临时日志，一旦进程崩溃，那些已经接收但还没进入写入流程的记录也会丢失。

三、降低风险的实践建议 #

针对这种大规模异步写入场景，我通常会做这些优化来避免数据丢失：

• 原子文件命名：写入时先用临时文件名（比如temp_001.tmp），等整个4MB文件写完并刷盘后，再原子重命名为正式文件名（比如record_001.dat）。这样即使写入失败，临时文件可以直接清理，不会出现损坏的正式文件，也能保证所有正式文件都是完整的。
• 记录幂等性设计：给每条学生记录分配唯一ID，后续如果出现数据丢失，可以通过重放上游流或者校验ID来补全缺失的记录，避免重复写入。
• 写入进度日志：维护一个简单的进度文件，记录已经成功写入的最后一条记录ID和对应的文件名。异常恢复时，从这个位置继续写入，不会重复处理已经完成的记录，也不会遗漏后续的记录。
• 强制刷盘+批量确认：每次写完一个4MB文件后，一定要调用系统刷盘接口，确保数据真正落到磁盘；同时和上游约定，只有当你返回“写入成功”的确认后，上游才可以丢弃这批记录，否则上游可以重试发送。
• 临时缓存兜底：可以把刚接收的记录先写入一个内存队列或者本地的临时日志文件（比如用append-only的方式），等写入正式文件成功后再删除临时缓存，这样即使进程崩溃，重启后也能从临时缓存恢复未写入的记录。

内容的提问来源于stack exchange，提问作者Phạm Văn Thông