LSM-Tree不是开箱即用的库，C++中需自行拼装MemTable、SST格式、Compaction调度、WAL和缓存等组件；轻量嵌入式实现须满足进程内加载、内存可控（≤50MB）、毫秒级启停、仅依赖glibc，推荐absl::btree_map或手写无锁跳表，SST采用扁平化mmap友好格式，Compaction需原子替换与WAL协同保障崩溃恢复。
LSM-Tree 不是开箱即用的库，C++ 里得自己搭骨架
没有现成的 lsm_tree::Engine 或 rocksdb::EmbeddedKV 可以直接 new 出来就跑。RocksDB、LevelDB 都是完整数据库，不是“引擎接口”；而真正轻量、可嵌入、纯内存+磁盘协同的 LSM 实现，必须从组件拼装：MemTable（跳表或红黑树）、SST 文件格式、Compaction 调度、WAL 日志、Block 缓存——每个模块都得选型或重写。
如果你的目标是「单机嵌入式」，意味着：
• 进程内加载，无网络/IPC 开销
• 内存占用可控（比如 ≤50MB 常驻）
• 启动/关闭在毫秒级
• 不依赖 glibc 以外的动态库（避免 musl 或嵌入式交叉编译翻车）
这些约束下，LevelDB 的代码太重（依赖 snappy、bzip2、gflags），RocksDB 更重（ColumnFamily、WriteBatch 多层抽象）。更可行的路径是：基于 abseil + std::pmr::monotonic_buffer_resource 实现 MemTable，用 mmap + 自定义二进制格式写 SST，Compaction 用惰性合并（不阻塞写）。
MemTable 必须用并发安全的跳表，别碰 std::map
std::map 和 std::unordered_map 在高并发写入下会成为瓶颈，且无法支持范围扫描的有序迭代。LSM 的 MemTable 核心要求是：插入快、迭代有序、支持前缀查找、线程安全但不重度锁争用。
立即学习“C++免费学习笔记（深入）”；
推荐直接用 absl::container::btree_map（编译期禁用异常和 RTTI 后约 120KB），或更轻量的 folly::AtomicUnorderedMap（如果允许 folly 依赖）。若想零依赖，手写一个无锁跳表（ConcurrentSkipList）比想象中简单：只实现 Insert()、Get()、RangeScan() 三个接口，用 std::atomic 控制 level 指针，跳表层数限制为 4～6 层即可满足 99% 场景。
容易踩的坑：
• 不做内存回收（delete 节点后指针悬空）→ 必须配合 epoch-based reclamation 或 hazard pointer
• 迭代器生命周期没绑定 MemTable 生命周期 → 扫描中途 MemTable flush 导致 segfault
• key 比较函数未处理 memcmp 陷阱（如 string_view 指向栈变量）→ 用 std::string 或明确 copy-on-write
SST 文件格式必须自己定义，别直接抄 LevelDB 的 .sst
LevelDB 的 .sst 文件包含 Block、Index、Filter 等多层结构，解析需完整读取 index block 到内存，对嵌入式场景不友好。更合适的做法是扁平化设计：
- Header（16 字节）：magic =
0x4C534D01，version = 1，block_count，total_key_size - Key-Value blocks（连续追加）：每个 block 固定 4KB，key_len + value_len + key_bytes + value_bytes，无压缩
- Footer（8 字节）：crc32 of header+blocks
这样 mmap 整个文件后，mmap_ptr + offset 就能随机访问任意 block，无需解析索引。Compaction 时直接 read()/write() 拷贝有效 block，不用解压/重组。缺点是空间放大率略高（约 1.2x），但换来的是启动速度（
注意：mmap(MAP_POPULATE) 在小文件上反而慢，建议仅对 ≥64KB 的 SST 文件启用；小于该阈值直接 read() 到 pre-allocated std::vector<uint8_t></uint8_t> 更稳。
Compaction 必须异步 + 限速，否则写入毛刺不可控
同步 compaction 会让 Put() 延迟从微秒级跳到百毫秒级（尤其当 L0→L1 合并多个 2MB SST）。正确做法是：把 compaction 任务扔进专用线程池（1～2 线程），并用 token bucket 限速。
示例策略：
• 每次 compaction 最多读取 4MB 原始数据
• 每秒最多触发 3 次 compaction（避免 I/O 饱和）
• L0 层 SST 数 > 4 个时才触发，防止抖动
• 合并后新 SST 文件名带时间戳+seq（如 000123_202405211422.sst），便于 debug 和清理
关键细节：
• compaction 线程必须持有 std::shared_mutex 的 shared_lock 才能读 MemTable，避免与写操作冲突
• 新 SST 写入后，原子替换旧文件（rename()），再删旧文件（不要用 unlink() 直接删，Windows 下可能失败）
• WAL 日志必须在 compaction 完成后才截断（ftruncate()），否则 crash 恢复会丢数据
最易被忽略的一点：compaction 过程中产生的临时文件，必须放在与主 DB 相同挂载点（否则 rename 跨设备失败），且路径不能含符号链接（realpath() 检查）。
