wal（预写日志）是保障数据可靠性与性能平衡的必要机制：必须先将操作追加写入带校验和、长度前缀和序列号的二进制日志并fsync成功，再更新内存；崩溃时通过重放完整日志恢复状态，避免直接依赖std::map+fstream导致的数据丢失。

为什么不能直接用 std::map + fstream 就完事？

因为宕机或程序崩溃时，std::map 在内存里的修改还没刷到磁盘，数据就丢了；而单纯每次写都 fsync() 又太慢。真实场景里得在「可靠性」和「性能」之间找平衡点——比如 WAL（Write-Ahead Logging）是绕不开的起点。

你不需要从零造 LSM 或 B+Tree，但得明确：简单 ≠ 随意序列化。下面几步是底线：

• 所有写操作先追加写入一个 wal.log 文件（带校验和、长度前缀、递增序列号）
• 成功 fsync() 后，再更新内存 std::unordered_map<:string std::string></:string>
• 读操作只查内存哈希表；启动时重放 wal.log 恢复状态
• 定期把内存快照 dump 成 snapshot.dat，并截断旧 WAL

WAL 文件格式怎么设计才不容易出错？

别用 JSON 或文本行——解析慢、容错差。用二进制固定头 + 可变体最稳妥。一个典型 record 结构：

4 字节 len | 1 字节 op_type (0=SET, 1=DEL) | 4 字节 key_len | key_bytes | 4 字节 val_len | val_bytes

关键细节：

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

• len 是整个 record 的字节数（不含自身），用于跳过损坏 record
• op_type 必须有，否则删键后重放会漏操作
• 每次写完 record 立即 write() + fsync()，不要缓冲
• 打开 WAL 时用 ios::ate | ios::binary，读取前先 seekg(0, ios::beg)

如何安全地做 snapshot + WAL 截断？

不能边 dump 边接受写入，否则 snapshot 和 WAL 状态不一致。必须用双缓冲 + 原子切换：

• 写新 snapshot 到临时文件 snapshot.tmp，dump 完毕后 fsync()
• 重命名 snapshot.tmp → snapshot.dat（Linux/macOS 上 rename() 是原子的）
• 记录当前 WAL 最后一条 log 的序列号 last_seq 到 snapshot 头部
• 截断 WAL：打开 wal.log，ftruncate() 到 last_seq 对应位置之后

注意：ftruncate() 前必须确保所有写线程已停，否则可能截掉正在写的 record。

多线程访问时哪些地方必须加锁？

不是所有操作都要锁全局。按粒度拆：

• WAL 写入：必须独占锁（std::mutex wal_mutex），因为 write() + fsync() 要串行
• 内存 map 读：用 std::shared_mutex，读多写少场景下能显著提升并发读性能
• snapshot 触发：由后台线程定时检查 size/时间阈值，触发时先 acquire wal_mutex，再 acquire map_mutex（写优先）
• 禁止在锁内做 fsync() 或长耗时 IO，容易卡住其他线程

真正难处理的是 crash 恢复逻辑——WAL 可能写到一半就断电，所以重放时要跳过不完整 record，靠 len 校验和双重判断。这点很容易被忽略，但决定了引擎是否真的“简单可靠”。

C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！