golang如何实现WAL预写日志_golang WAL预写日志实现步骤

WAL（Write-Ahead Log）的可靠性，归根结底取决于一个核心假设：日志写入必须在数据修改之前落盘。如果这个前提不成立，整个系统的一致性保障就崩塌了。下面这几个关键点，是实践中最容易踩坑的地方，也是真正区分“能用”和“生产级”的分水岭。

WAL 文件写入必须用 os.O_SYNC 或 os.O_DSYNC

不加同步标志的 os.OpenFile 写入，数据可能只停留在页缓存或磁盘写缓存里，进程崩溃时 WAL 记录就丢了——这直接破坏 WAL “先落盘再改数据”的语义。Linux 下推荐用 os.O_WRONLY | os.O_CREATE | os.O_APPEND | os.O_SYNC；macOS 对 O_SYNC 支持不稳定，可降级为 os.O_DSYNC（仅同步数据，不强制同步元数据）。fsync() 手动调用不是替代方案，因为 Write() 返回成功 ≠ 数据已刷盘，必须依赖打开时的标志。

sync.WriteAt 不适合 WAL，要用 file.Write 配合 os.O_APPEND

WAL 要求严格追加、无竞态、不覆盖。用 WriteAt 需自行管理偏移量，多 goroutine 并发写时极易错位或覆盖。而 os.O_APPEND 保证每次 Write 原子性地追加到文件末尾，内核层面完成偏移定位。注意：即使开了 O_APPEND，仍需用 sync.Mutex 或 sync.RWMutex 保护日志条目序列化过程（比如 JSON 编码、长度前缀写入），否则多个 goroutine 同时写一个条目会粘包。

日志条目必须带长度前缀，不能依赖换行或 JSON 结构

WAL 是二进制流，不是文本日志。靠 bufio.Scanner 按行读或 json.Decoder 直接解码会失败——前者无法处理跨缓冲区的换行，后者在解析中断时状态不可恢复。正确做法是：写入时先写 4 字节大端序长度（binary.Write(w, binary.BigEndian, uint32(len(buf)))），再写原始字节；读取时先读 4 字节得长度 n，再读 n 字节。这样即使文件损坏，也能跳过坏条目继续解析后续有效记录。

滚动与清理必须原子替换，避免读写冲突

WAL 文件不能边写边删。常见错误是 os.Remove 正在写的文件——Linux 允许但会导致写入返回 EBADF，Windows 直接报错。安全做法是：当日志大小超阈值（如 64MB），调用 file.Close()，用 os.Rename 将旧文件重命名为 xxx.001，再 os.OpenFile 创建新文件。重命名是原子操作，且旧文件句柄仍有效，读取器可继续消费完已打开的文件。清理历史文件时，只删那些已完全被 checkpoint 覆盖且无任何 reader 引用的 .001、.002 文件。

回到开头那句话：WAL 的难点不在写，而在崩溃恢复时如何精准定位最后一条完整日志——长度前缀校验、文件末尾截断处理、以及 checkpoint 位置与 WAL 文件名的映射关系，这三处最容易被忽略。把这些细节兜住，才算真正吃透了预写日志。