Go标准库无LSM-Tree实现，手写MemTable和WAL风险高：MemTable需并发写入、快照隔离、迭代器遍历及内存触发flush，WAL要求原子写入、可控fsync与幂等重放；推荐直接使用Pebble或Badger等成熟库。
想在Go里用上LSM-Tree？现实是，标准库并没有提供现成的实现，也没有官方维护的生产级库。用map或者sync.Map搭个架子，应付一下演示场景或许还行，但真要投入生产环境，要么依赖经过严格验证的成熟封装，要么就得自己动手，把核心机制里的每一个坑都填平。
为什么别手写 LSM-Tree 的 MemTable 和 WAL
MemTable听起来好像就是个有序的内存表，但它的实现复杂度远超treeMap加上一把sync.RWMutex锁那么简单。它需要支持多路并发写入、保证快照隔离级别的读取、提供稳定的迭代器遍历，还得在内存达到阈值时精准触发flush操作。而WAL（预写日志）的坑就更深了：每一次写入都必须保证原子性，fsync的调用频率必须可控，系统崩溃后的日志重放还必须做到幂等。实践中，下面这几个错误相当常见：
- 使用
os.WriteFile来写WAL：这无法保证操作系统的落盘顺序，一旦崩溃，日志文件很可能被截断，导致数据永久丢失。 - MemTable采用
sort.Slice进行动态排序：在频繁插入的场景下，性能会出现断崖式下跌。 - 忽略快照语义：读取请求可能会看到正在被flush的部分数据，一致性就被破坏了。
所以，一个更稳妥的建议是，直接使用成熟的第三方库，比如pebble（由CockroachDB团队开源）或badger（由Dgraph团队维护）。它们都用Go编写，提供了清晰的API，并且完整实现了WAL、Compaction和版本集管理等核心机制。
用 pebble 构建带 TTL 的键值存储
pebble本身并不直接支持TTL（生存时间）功能，但我们可以通过巧妙的键编码加上后台扫描来模拟实现。这里的关键挑战，不在于“如何添加过期逻辑”，而在于“如何避免为了清理过期键而全量扫描SST文件，导致系统卡顿”。
立即学习“go语言免费学习笔记（深入）”；
- 将过期时间戳编码到键的前缀中，例如：
key = append([]byte(fmt.Sprintf("%d_", expireAt)), originalKey...)。 - 设置
pebble.Options.ReadOnly = false，并启用Compaction过滤器：在Filter: func(key []byte) bool { ... }函数中，判断并丢弃已过期的键。 - 注意，千万别禁用WAL（即
Options.DisableWAL = true）。即使是只读场景，也需要WAL来保证持久性，否则重启后尚未flush的MemTable数据就会丢失。
需要特别提醒的是，pebble的Iterate迭代器默认不会校验TTL。因此，在读取逻辑中，必须自行解码键并判断时间戳，否则可能会返回本应过期的“脏数据”。
badger 的 Value Log（vlog）磁盘碎片问题
badger的设计有一个特点：它将value单独存储在Value Log（vlog）文件中。这样做的好处是能避免大value在Compaction时被重复写入，但缺点也随之而来——vlog文件不做原地更新。任何删除或覆盖操作，都只是在原位置做标记，真正的空间回收要依赖后台的GC（垃圾回收）进程。有几个坑很容易踩到：
- GC的默认执行频率是每小时一次。如果业务是小文件密集写入型，vlog文件可能会急速膨胀，在磁盘被占满之前，往往缺乏明显的预警。
- 如果将
ValueThreshold参数设置得过小（比如<1KB），会导致大量本该放入SSTable的小value也进入vlog，进一步加剧碎片问题。 - 调用
DB.RunValueLogGC(0.7)执行GC时，如果磁盘剩余空间不足，GC会静默失败。日志里通常只有一句skipping GC due to low disk space，很容易被忽略。
因此，在生产环境中，务必监控value_log_size和disk_usage_percent这两个关键指标。同时，建议将触发GC的阈值从默认的0.7调整为更保守的0.5，为磁盘空间留出足够的缓冲余地。
说到底，LSM-Tree的Compaction策略、层级划分、读放大控制，这些都不是靠一两个配置开关就能解决的。它们严重依赖于具体的工作负载特征，需要反复调试。即便是使用pebble这样的优秀库，其Levels配置数组中，每一层的TargetFileSize和Compression参数也都需要经过实际测试来敲定——不存在通用的最优解，只有针对当前业务来说“最不差”的配置组合。
