彻底解决 RocksDB Write Stall：当 pending compaction bytes 激增，如何平滑限流避免延迟抖动？

在基于 LSM-Tree（Log-Structured Merge-Tree）架构的存储引擎（如 RocksDB）中，Write Stall（写入停顿） 是最令架构师和 DB 运维人员头疼的性能杀手。当写入速度远超后台 Compaction（合并）速度时，RocksDB 会强制拉低前台写入速率甚至完全阻塞写入，以防止内存溢出（OOM）或空间放大失控。

而在所有 Write Stall 触发条件中，pending compaction bytes（等待合并的字节数）激增 是最难平滑处理的一个。本文将深入探讨 RocksDB Write Stall 的触发机理，并重点解析当 pending compaction bytes 激增时，如何通过参数调优、主动限流等策略，平滑降低前台写入速率，消灭突发的延迟毛刺。

一、 RocksDB Write Stall 的三大触发器

RocksDB 内部有三个主要的监控维度，任何一个达到阈值都会触发 Write Stall：

                    ┌──────────────────────────┐
                    │     Incoming Writes      │
                    └────────────┬─────────────┘
                                 │
         ┌───────────────────────┼───────────────────────┐
         ▼                       ▼                       ▼
┌─────────────────┐     ┌─────────────────┐     ┌──────────────────┐
│   MemTable 数量  │     │   L0 文件数量   │     │ Pending Bytes    │
│  (Max Buffer)   │     │   (L0 Files)    │     │  (Compaction)    │
└─────────────────┘     └─────────────────┘     └──────────────────┘

1. MemTable 数量过多

当写入的数据填满活跃的 MemTable 后，会将其转为 Immutable MemTable 并等待 Flush 到 L0 层。如果 Flush 速度慢于写入速度，导致 Immutable MemTable 数量达到 max_write_buffer_number 限制，前台写入将被彻底阻塞（Stop）。

2. Level 0 文件积压

因为 L0 层文件之间存在 Key 范围重叠，读取时需要扫描所有 L0 文件。为了防止读放大失控：

当 L0 文件数达到 level0_slowdown_writes_trigger（默认 20）时，触发 Slowdown（限流）。
当 L0 文件数达到 level0_stop_writes_trigger（默认 36）时，触发 Stop（停顿）。

3. Pending Compaction Bytes 积压

这是衡量 LSM-tree 整体合并压力的终极指标，代表当前所有待合并的数据总量估算值：

当估计值达到 soft_pending_compaction_bytes_limit（默认 64GB）时，开始 Slowdown。
当估计值达到 hard_pending_compaction_bytes_limit（默认 256GB）时，强制 Stop。

二、为什么 Pending Compaction Bytes 激增会导致“延迟悬崖”？

在生产环境下，当出现大批量范围更新、TTL 集中过期或大规模导入时，pending compaction bytes 会在极短时间内拉升。

此时，RocksDB 默认的限流机制存在明显的**“悬崖效应”（Cliff Effect）**：

断崖式降速：一旦越过 soft_pending_compaction_bytes_limit，RocksDB 会将前台写入速率直接限制到 delayed_write_rate（默认 16MB/s）。如果系统平时的写入吞吐是 500MB/s，突降到 16MB/s 会导致前台请求瞬间堆积，P99 延迟暴涨数十倍。
算法震荡：RocksDB 内部采用的是一种动态逼近算法。当检测到积压，它会按照因子（如 0.6）不断调低写入速度；一旦后台 Compaction 释放了空间，又会逐步释放限制。这种机械的调整导致写入速率呈“锯齿状”剧烈震荡，无法提供平滑的 QPS 曲线。

三、平滑降低前台写入速率的四大缓解策略

为了避免写放大触发“硬限流”，我们需要采取一系列组合拳，使前台写入速率在 pending compaction bytes 积压时呈渐进式、平滑式下降。

1. 拓宽 Soft/Hard Limit 缓冲带，拉平限流斜率

默认配置下，Soft Limit 到 Hard Limit 的区间太窄，或者两者的比例设置不合理，导致系统几乎没有时间在 Soft Limit 阶段消化积压，就直接撞上了 Hard Limit。

优化方案：

增大 hard_pending_compaction_bytes_limit 与 soft_pending_compaction_bytes_limit 的差值。
科学配置 delayed_write_rate，避免使用默认值（16MB/s 往往过低）。应将其设置为磁盘连续写入带宽的 50%~70%。

# 典型生产环境大吞吐配置 (针对 NVMe SSD)
soft_pending_compaction_bytes_limit = 128GB  # 提升软限制阈值
hard_pending_compaction_bytes_limit = 512GB  # 给后台 Compaction 留出充足的消化空间
delayed_write_rate = 134217728               # 128MB/s，不至于让前台写入直接“失速”

2. 启用并调优 RocksDB 动态速率自适应（Rate Limiter）

RocksDB 内部自带了一个基于令牌桶算法的 RateLimiter。利用它，我们可以在用户态对写入带宽进行全局匀速整形，而不是依赖底层的 Write Stall 暴力拦截。

#include "rocksdb/rate_limiter.h"

// 创建一个限制总写入带宽为 300MB/s 的 RateLimiter
// 参数3：refill_period_us，默认 100,000us (100ms)，可调小到 10,000us (10ms) 以获得更平滑的流量
std::shared_ptr<rocksdb::RateLimiter> rate_limiter(
    rocksdb::NewGenericRateLimiter(300 * 1024 * 1024, 10 * 1000, 10)
);

rocksdb::Options options;
options.rate_limiter = rate_limiter;

平滑原理：RateLimiter 会在底层检测 pending_compaction_bytes 的趋势。当发现积压在增长时，我们可以在应用层通过监控 GetLiveFilesMetadata 或 GetIntProperty("rocksdb.estimate-pending-compaction-bytes")，动态调小 RateLimiter 的 set_bytes_per_second。
效果：前台写入在距离 Soft Limit 还有相当一段距离时，就已经被微调限速。由于限速是渐进的（例如每次降低 10%），前台客户端可以平稳感知，避免了突发的超时。

3. 优化后台 Compaction 吞吐，加速消灭 Pending Bytes

要想从根本上解决 Write Stall，除了前台减速，更关键的是后台提速。必须保证 Compaction 线程有足够的系统资源来合并数据。

调大线程池：增加后台 Compaction 线程数。

max_background_jobs = 16  # 允许 RocksDB 自动分配足够多的线程给 Flush 和 Compaction

优化 L0 -> L1 Compaction 的优先级：
L0 到 L1 的 Compaction 往往是整个 LSM-Tree 的瓶颈所在，因为这涉及到跨层重叠 Key 的完全重写。开启 optimize_filters_for_hits 和确保使用高优先级的线程池（Env::Priority::HIGH）来处理 L0->L1 合并，能极大缩短 pending 状态。

4. 采用 Level Style Compaction 的 Dynamic Level Size Base 策略

如果开启了 level_compaction_dynamic_level_bytes = true，RocksDB 会根据最底层（L_max）的实际数据量，动态计算出各中间层的目标大小。

优势：这可以显著减少因为某一层突然数据爆满而向下层合并时产生的 pending compaction bytes 峰值。它能让数据在各层分布更加均匀，使 Compaction 的触发更加连续、微量，从而消除了单次大规模 Compaction 带来的 IO 暴涨。

四、生产环境实战：自研主动平滑限流算法

如果 RocksDB 内部的调整仍无法完全消除业务侧的延迟抖动，推荐在 SDK/数据库代理层 实现一套主动平滑限流算法：

[ 客户端请求 ] 
      │
      ▼
┌────────────────────────────────────────────────────────┐
│ 1. 周期性（如 50ms）拉取 RocksDB Metrics：               │
│    pending_bytes = estimate-pending-compaction-bytes   │
└──────────────────────────┬─────────────────────────────┘
                           │
                           ▼
┌────────────────────────────────────────────────────────┐
│ 2. 计算当前限流比例（Sigmoid 曲线函数）：                  │
│    Ratio = 1 / (1 + e^( -k * (pending_bytes - Center) ))│
└──────────────────────────┬─────────────────────────────┘
                           │
                           ▼
┌────────────────────────────────────────────────────────┐
│ 3. 根据 Ratio 动态调节应用层限流器的 Token 产生速率         │
│    (平滑衰减，无陡峭折线)                                │
└────────────────────────────────────────────────────────┘

通过这种在上层漏斗进行的温和拦截，可以让前台吞吐随着后台压力的增大呈一条优雅的 S 型曲线下降，彻底告别 Write Stall 带来的延迟恶梦。

总结

解决 RocksDB 的 Write Stall 问题，核心思想是**“以空间换时间，以主动避被动”**。不要等到 pending compaction bytes 触及硬限制时让引擎去踩刹车，而应该通过科学配比 Soft/Hard Limit 阈值、合理配置 delayed_write_rate、引入主动限流器，以及最大化后台 Compaction 能力，将突发的压力稀释在时间的河流中，维持系统高可用和 P99 延迟的绝对稳定。