LSM-Tree自诞生以来一直饱受Write Stall/Stop困扰——写压力大时延迟和吞吐剧烈波动，甚至写流量跌零。这一问题在学术界与工业界至今没有通用解法。

　　本文介绍阿里云瑶池旗下的云数据库Tair Serverless KV存储引擎（FlexEngine）中的创新方案：首次在LSM上建模生产者-消费者模型，从机制上彻底消除Write Stall，该方案已获得专利授权。

　　01

　　什么是Write Stall：LSM类引擎的共性痛点

　　LSM-Tree（以RocksDB/LevelDB为典型开源实现）被广泛应用于各类数据库产品，其优势突出：写性能优异、数据连续存储、压缩率高、空间成本低。但它有一个"与生俱来"的问题——Write Stall/Stop（写卡顿与写停滞）。

　　其根源在于LSM的写入方式：用户写入先落内存Memtable即返回（这是LSM写性能好的原因），再由后台Flush/Compaction线程逐层整理落盘。当用户写入速度持续超过后台线程的处理速度，数据在某一层不断堆积，引擎便会主动"踩刹车"：

　　堆积超过soft limit → 进入Stall状态，写入被限速；

　　堆积超过hard limit → 直接停写（Stop），服务不可用。

　　触发条件有三个：Immutable Memtable数目、Level 0文件数目、待Compaction字节数（pending compaction bytes）。

　　更糟糕的是，原生引擎的限速逻辑十分粗糙：进入Stall后按固定系数（0.8/0.6）连续折减令牌，退出后再按固定系数（1.25/1.4）恢复——它不感知引擎真实的处理能力，只是"猜"。结果就是：突发写入没有任何约束、限速起点与真实能力脱节、多Column Family（CF）之间相互干扰，最终表现为吞吐锯齿状剧烈抖动、延迟毛刺高达数百秒。业界已有方案（无论在引擎内部还是在引擎上层做流控）均只能缓解抖动的剧烈程度，无法从根本上避免Stall。

　　对于承诺稳定SLA的云产品而言，这种不可预测的性能悬崖是不可接受的。

　　02

　　核心思路：把LSM建模为生产者-消费者模型

　　我们换了一个视角看这个问题：LSM本质上是一个生产者-消费者系统——用户是生产者，把数据写进Memtable；后台Flush/Compaction线程是消费者，把数据逐层整理至稳态。Write Stall的本质，就是生产速度长期超过消费速度后的"仓库爆仓"。

　　历史上的优化思路大多在"提高消费能力"（减少写放大、引入新硬件）或"加大缓冲队列"（延迟触发条件）上做文章，但消费能力总有上限，堆积迟早发生。我们的思路是反过来：实时算出引擎当前的真实消费能力，平稳地把生产速度控制在这个能力之内。

　　消费能力如何量化？关键洞察是：LSM每写入1字节用户数据，后台需要搬运"读写放大倍数"的字节。因此引擎的实时消费能力可以建模为：

　　引擎写能力 = 磁盘可用带宽 / (实时读写放大 RWA(t) + 1)

　　其中读写放大RWA(t)随数据量、层数动态变化，"+1"代表WAL写入开销。只要限流跟得上这个动态值，堆积就不会发生，Stall的触发条件永远不会被满足。

　　03

　　方案架构：两级令牌闭环

　　方案基于两个令牌管理组件形成控制闭环：

　　RateLimiter（磁盘带宽管理）：管理所有磁盘读写操作（用户读写文件、后台Flush/Compaction）的带宽配额，保证后台任务不挤占前台、磁盘不被打满；

　　WriteController（前台写流控）：用户每次写入前申请令牌，申请量为"写入数据量 × write_penalty(t)"，其中write_penalty(t)基于实时读写放大计算；令牌派发速度即当前写链路可用的磁盘带宽。

　　每当LSM树结构发生变化（Memtable切换、Flush/Compaction完成），系统重新计算读写放大并更新write_penalty——限流始终追踪引擎的真实能力，而非事后补救。

　　04

　　让模型真正工作的关键设计

　　朴素模型距离生产可用还有几个关键问题要解决：

　　1. 读写放大的精确统计与平滑。瞬时读写放大若统计偏大会白白损失性能，偏小则仍会堆积。我们按层统计Compaction的实时读写放大，并做加权平滑（累计参与Compaction的数据量超过文件阈值80%、最多回溯5次），同时过滤掉不会阻塞前台写的Compaction类型，消除了统计噪声导致的性能凹坑。

　　2. 允许写入短时超过引擎能力（Burst）。我们将write_penalty设计为分段的：当LSM处于健康状态时，允许用户写入跑到引擎能力的150%；当出现数据堆积苗头（原Stall触发条件）时，回落至100%的真实消费能力——注意，此时不再是Stall，而是精确匹配引擎能力的平稳限流。这带来三重收益：统计偏大时不损失性能、利用适度堆积降低写放大、满足用户对突发流量的真实需求。

　　3. 精细化的Flush/Compaction调度。限流模型成立的前提是后台消费链路本身不能有瓶颈：通过RateLimiter让Flush的磁盘带宽优先级高于Compaction；调整Memtable的soft limit至容量的一半，更早对齐真实写能力；通过subcompaction并发保证Level 0能被及时消化。实测中Memtable堆积从未触及hard limit。

　　4. 多CF支持。多个CF共享后台线程池，我们引入全局write_penalty（取各CF读写放大的最大值），估计偏保守但配合Burst能力，实测无明显性能损失。

　　05

　　实测效果：最大延迟改善2~3个数量级

　　以16线程持续压测1KB value为例（模拟产品真实配置），优化前后对比：

　　单CF场景最大延迟从数百秒降至36ms，改善超过3个数量级；多CF场景最大延迟从33891ms降至37.4ms，改善近3个数量级（value更大时提升更明显）。下面两图分别为优化后单CF与多CF场景的写吞吐曲线：

　　优化后写吞吐随数据量增长平滑收敛于引擎真实能力，全程无一次Stall/Stop，且平均吞吐与原生引擎基本持平——稳定性不是用性能换来的。

　　06

　　总结

　　云数据库Tair Serverless KV通过磁盘带宽监控与管理、基于生产者-消费者模型的引擎写能力实时计算、前台写流量精确控制、Compaction调度调优这一系列技术，在不牺牲写吞吐的前提下，彻底消除了LSM引擎的Write Stall/Stop，使产品在极端写压力下依然保持稳定可预测的写延迟。

　　对用户而言，这意味着：日志采集、消息缓冲、批量导入等持续高写入场景，再也不必为突如其来的吞吐断崖式下跌预留缓冲容量与重试逻辑——写性能稳定，是Tair Serverless KV的产品承诺。