Go语言LSM树合并策略详解

本文深入剖析了Go语言中LSM Tree存储引擎（Pebble与Badger）在真实生产场景下面临的核心compaction难题：如何让合并节奏精准匹配动态读写负载，避免L0文件堆积导致读延迟飙升、GC静默失败引发磁盘空间失控、手动compact破坏快照一致性，以及错误切换策略引发IO雪崩；强调参数调优不是套用默认值，而是围绕L0膨胀系数、磁盘余量校验、显式快照隔离、层级容量模型等关键机制进行深度定制，并指出唯一可靠的方案是基于真实流量压测，动态校准TargetFileSize与SizeRatio，让compaction真正成为可控的“数据流节拍器”，而非不可预测的性能黑洞。

pebble 的 compaction 触发逻辑怎么配才不卡住读

pebble 默认的 compaction 调度是“被动响应型”：只有当某层文件数或大小超限，才会触发。但实际写入密集时，L0 文件暴涨，L0SublevelCompactions 可能来不及合并，导致点查要扫几十个 L0 SSTable，延迟飙升。

关键不是调大 Levels[i].TargetFileSize，而是控制 L0 的“膨胀系数”：

• 把 Options.L0StopWritesThreshold 设为 12（默认是 12，但很多人没意识到它真会 stop write）——一旦 L0 文件数 ≥12，写入阻塞，强制 compaction 跟上
• 降低 Options.L0CompactionThreshold 到 4（默认是 4，但建议显式设，避免被误认为可忽略）——L0 文件数 ≥4 就启动 compaction，别等满
• 禁用 Options.DisableWAL = true：即使只读也要 WAL，否则重启后未 flush 的 MemTable 丢失，compaction 前提就没了

badger 的 value log GC 为什么总失败

badger 把大 value 单独存 vlog，GC 是唯一回收手段，但默认配置在生产环境极易静默失败。

最常踩的坑是磁盘空间判断太宽松：

• DB.RunValueLogGC(0.7) 中的 0.7 是“vlog 占用率阈值”，但 GC 运行前会检查剩余磁盘空间是否 >1GB —— 如果只剩 800MB，它直接跳过，日志只写 skipping GC due to low disk space
• ValueThreshold 设太小（如 1KB），会导致大量小 value 进 vlog，GC 时要重写巨量碎片文件，IO 拉满且易超时
• 监控必须盯死两个指标：value_log_size（所有 vlog 总大小）和 disk_usage_percent（挂载点使用率），不能只看 badger 自己的 GetDiskUsage

手动触发 full compaction 时为啥数据反而查不到了

调 pebble.DB.Compact 或 badger.DB.RunValueLogGC 后出现“刚写进去的 key 突然查不到”，通常不是 compaction 漏了数据，而是 snapshot 语义被破坏。

根本原因是：compaction 过程中，旧文件还没删、新文件已写入，但迭代器（iterator）没做版本隔离：

• pebble 的 Iterate 默认不校验 TTL，如果 key 编码里带时间戳（如 append([]byte(fmt.Sprintf("%d_", expireAt)), originalKey)），必须在迭代时自己 decode 并过滤，否则返回过期脏数据
• badger 的 View 函数创建只读事务时，底层 snapshot 是基于当前 head 的，但如果 compaction 正在重写 vlog，View 可能读到部分更新状态
• 正确做法：用 DB.NewSnapshot() 显式获取快照，再用该快照创建 iterator，确保一致性视图

为什么 Leveled 和 Universal 策略不能随便换

pebble 默认用 Leveled，badger 用的是类似 Universal 的变种，但直接改 Options.Levels 数组或硬切策略，往往导致 compaction 频率失控、磁盘 IO 打满。

差异不在 API 开关，而在层级膨胀模型：

• Leveled 要求每层容量严格指数增长（如 L1=10×L0，L2=10×L1），Levels[i].SizeRatio 必须实测；设成 5 可能让 L2 堆积过慢，L1 持续 compaction
• Universal 更依赖文件数量而非大小，Levels[0].NumFilesStallThreshold 一设错，L0 文件数冲到上百，读放大直接破百
• 真实 workload 决定策略：key 分布倾斜（如 10% key 占 90% 访问）适合 Leveled；写入速率波动大、value 大小不均，Universal 更稳

真正难的从来不是选哪个 compaction 策略，而是让 compaction 的输出节奏匹配你的读写毛刺曲线——没有预设参数能扛住凌晨批量导入 + 白天高并发查询的混合压力，必须用真实流量压测后调 TargetFileSize 和 SizeRatio。

好了，本文到此结束，带大家了解了《Go语言LSM树合并策略详解》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！