如何设计 LSM-Tree 存储引擎的 Compaction 限速机制，彻底解决 P99 延迟抖动？

在基于 LSM-Tree（Log-Structured Merge-tree）架构的存储引擎（如 RocksDB、TiKV 等）中，Compaction（压实） 是维持系统健康运转的核心机制。它通过在后台合并 SStables，清理过期数据并减少空间放大与读放大。

然而，Compaction 也是臭名昭著的“性能杀手”。大吞吐量的后台 I/O 会与前台的用户读写请求激烈争抢磁盘带宽、CPU 以及锁资源。在生产环境中，这种资源争抢最直接的后果就是前台请求的 P99、P999 尾部延迟（Tail Latency）出现严重的毛刺和抖动。

要解决这个问题，仅仅依靠“多塞硬件”是无济于事的，必须在存储引擎内部设计一套精密的吞吐限速器（Rate Limiter）。本文将从工业级存储引擎的设计视角，深入探讨如何构建一套既能防止 P99 击穿，又能避免前台写停顿（Write Stall）的 Compaction 限速系统。

一、 为什么传统的限速方案在 LSM-Tree 中会失效？

在开始设计之前，我们需要厘清为什么简单的限速方案（如静态令牌桶、操作系统级 I/O 调度）无法解决 LSM-Tree 的延迟毛刺。

1. 写停顿（Write Stall）与限速的悖论
   LSM-Tree 的前台写入速度与后台 Compaction 速度存在强耦合。如果对 Compaction 限速过死，后台合并跟不上前台写入，导致 L0 层文件积压或 Pending Compaction Bytes 超过阈值，存储引擎就会触发“写停顿”，直接将前台写入速度强制拉低甚至挂起。此时，P99 延迟不仅没有改善，反而会彻底崩溃。
2. 内核 I/O 调度的局限性（cgroups / ionice）
   操作系统的 I/O 调度器（如 CFQ、BFQ）无法感知 LSM-Tree 内部的逻辑状态。它们只知道读写块数据，无法区分当前的写操作是关键的 MemTable Flush（必须立刻完成，否则阻塞写入），还是普通的 L6 层后台 Compaction（可以慢慢进行）。
3. 缓冲 I/O 带来的“限速隐形”
   如果存储引擎没有使用 Direct I/O，而是依赖操作系统的 Page Cache，那么引擎内部计算的 I/O 吞吐只是“写入 Page Cache 的速度”，而真正引发物理 I/O 阻塞的是内核脏页异步刷盘（Writeback）时的 I/O 暴涨。

因此，一个合格的 LSM-Tree 限速器必须是应用层感知的、自适应的、分级优先度的、且能够打通整个 I/O 栈的系统。

二、 核心架构：多级优先级令牌桶（Token Bucket）

工业级限速器的底层算法通常基于令牌桶（Token Bucket），因为相比漏桶（Leaky Bucket），令牌桶能更好地容忍突发流量（Burst），这符合存储引擎在处理某些关键元数据或小文件时的需求。

为了防止 P99 击穿，限速器必须对不同的 I/O 操作进行分级治理。我们可以将限速器设计为支持多级优先级的令牌分配系统：

                    [ 令牌生成器 (Refill Thread) ]
                                 │ (每 N 毫秒填充令牌)
                                 ▼
                     ┌──────────────────────┐
                     │    全局主令牌桶      │
                     └──────────────────────┘
                                 │
         ┌───────────────────────┼───────────────────────┐
         │ (高优先级获取)        │ (中优先级获取)        │ (低优先级获取)
         ▼                       ▼                       ▼
┌──────────────────┐    ┌──────────────────┐    ┌──────────────────┐
│ 1. 前台用户读写  │    │ 2. MemTable Flush│    │ 3. Compaction    │
│  (不限速/秒级响应) │    │  (高优先级限速)   │    │  (严格平滑限速)  │
└──────────────────┘    └──────────────────┘    └──────────────────┘

1. 优先级划分原则

• Priority 1：前台用户 Read/Write
  通常不经过限速器，或者拥有无限额度的优先兑换权。这是保证 P99 延迟的第一步。
• Priority 2：Flush（MemTable 刷盘）
  分配高优先级。如果 Flush 被限速变慢，内存中的 MemTable 无法释放，会立刻触发前台写停顿。
• Priority 3：Low-level Compaction（如 L0 -> L1）
  分配中优先级。L0 文件数量直接影响前台读性能（读放大）和写停顿阈值，需要较快完成。
• Priority 4：High-level Compaction（如 L4 -> L5 -> L6）
  分配低优先级。这些合并涉及的数据量极大，但对前台写入的即时影响较小，必须施加最严格的限速。

三、 关键设计一：自适应动态限速算法（Adaptive Rate Limiting）

静态设置一个固定的 Compaction 带宽（例如限制在 50MB/s）是极其危险的。在业务高峰期，50MB/s 可能会因为跟不上写入而导致写停顿；在业务低峰期，限制在 50MB/s 又浪费了磁盘富余的带宽。

因此，限速器必须引入反馈控制闭环，根据系统当前的负载指标，动态调整 Compaction 的限速阈值。

1. 反馈因子的选择

自适应算法应当监控以下核心指标：

• pending_compaction_bytes：等待合并的后台数据量。这是预测写停顿最敏感的指标。
• 前台写入速率（write_rate）。
• 当前 SSD 的实际 I/O 延迟（通过前台 Read 的 P99 监控）。

2. 动态调整策略（以 RocksDB Auto-Tuned Limiter 为例）

我们可以设计一个基于温和逼近与快速释放的控制算法。

设当前设定的 Compaction 最大限制速率为 $V(t)$，基础速率为 $V_{base}$，磁盘物理带宽上限为 $V_{max}$。

1. 安全区间（Pending Bytes 处于低位）：
   保持极低的 Compaction 速率，甚至阶段性暂停大文件 Compaction，将所有磁盘带宽让给前台读写，以确保 P99 延迟处于极低水平。
   $$V(t) = V_{base}$$

2. 警戒区间（Pending Bytes 开始累积）：
   当后台积压数据超过阈值 $H_1$ 时，开始线性提升 Compaction 速率，释放后台压力：
   $$V(t) = V_{base} + k \cdot (\text{Pending Bytes} - H_1)$$

3. 危险区间（Pending Bytes 逼近写停顿阈值 $H_2$）：
   一旦积压量超过 $H_2$，此时系统的首要矛盾已经转换为“避免写停顿”。限速器必须果断将限制放开至最大（甚至完全不限速），全力执行 Compaction，直到积压量跌回安全线。
   $$V(t) = V_{max}$$

通过这种自适应调整，系统在平时能保持极低的物理 I/O，消除了 Compaction 带来的延迟毛刺；在面临写放大压力时，又能提前平滑升速，避免了突然卡死的写停顿。

四、 关键设计二：细粒度 I/O 调度与线程锁优化

在工程实现上，很多限速器在算法层天衣无缝，但一旦上线就会因为锁竞争（Lock Contention）或线程饥饿导致前台延迟不降反升。

1. 消除全局锁竞争：线程局部令牌缓存（Thread-Local Token Budget）

在多线程高并发写入时，如果所有后台 Compaction 线程和前台线程都去争抢一个全局限速器（RateLimiter）的 Mutex 锁，这个锁本身就会变成前台 P99 延迟的杀手。

优化方案：

• 引入 Thread-Local Budget（线程局部额度） 机制。
• 每一个 Compaction 线程一次性从全局令牌桶中申请一个较大分片（例如 1MB - 4MB 的额度）存放在本地线程变量中。
• 线程内部的每一次实际 I/O 写（如每次 Write 32KB 的 SST Block）先扣减 Thread-Local 的额度。
• 只有当本地额度扣减完毕时，才去竞争全局锁申请下一个分片。这可以将锁竞争的频次降低 2 个数量级以上。

// 简化的线程局部令牌获取伪代码
class ThreadLocalRateLimiter {
private:
    GlobalRateLimiter* global_limiter;
    thread_local size_t local_budget = 0;

public:
    void RequestToken(size_t bytes) {
        if (local_budget >= bytes) {
            local_budget -= bytes;
            return;
        }
        
        // 本地额度不足，从全局批量申请
        size_t batch_size = std::max(bytes, 4 * 1024 * 1024); // 默认申请 4MB
        global_limiter->Acquire(batch_size); 
        local_budget += batch_size;
        
        local_budget -= bytes;
    }
};

2. 平滑的 I/O 分片（Slice & Sleep）

如果一个 Compaction 线程一次性写入一个 64MB 的大 Block，然后限速器让其挂起（Sleep）1 秒钟，这在宏观上确实实现了 64MB/s 的限速，但在微观上，那瞬间写入的 64MB 会将 SSD 的队列（Queue Depth）瞬间塞满，导致排在后面的前台读请求出现数百毫秒的延迟。

优化方案：
限速器必须强制要求 Compaction 线程进行细粒度的 I/O 分片。每次写入的数据块不得超过一个微小的阈值（如 16KB - 64KB），每写完一个分片，就去调用一次限速器的 RequestToken。如果额度不足，则进行微秒级（Microseconds）的 usleep。
通过这种**“高频、微量、多次”**的 Sleep 机制，将 I/O 压力均匀地平摊到时间轴上，消除 I/O 瀑布效应。

五、 关键设计三：打通操作系统内核（Direct I/O 与 Cgroup 联动）

如果存储引擎使用标准的文件系统 I/O（Buffered I/O），限速器往往会形同虚设。因为 write() 系统调用在把数据拷贝到 Page Cache 后就立刻返回了，存储引擎误以为 I/O 已经平滑完成。然而，当内核脏页达到一定比例，或者 fsync 被调用时，内核会突然爆发式地将数据刷入磁盘，造成 I/O 挤压。

1. 采用 Direct I/O（直接 I/O）

要让 Rate Limiter 真正发挥作用，强烈建议对后台 Compaction 和 Flush 开启 Direct I/O。

• 绕过 Page Cache，让存储引擎的写入直接对应到磁盘的物理写入。
• 使得 Rate Limiter 能够精准控制每一物理字节写入 SSD 的时机，实现真正的“所限即所得”。

2. 协作式内核 I/O 调度

在 Linux 操作系统层面，可以通过在存储引擎初始化后台线程时，使用 ioprio_set 系统调用将 Compaction 线程的 I/O 优先级设置为 Idle Class（仅在系统无其他 I/O 时运行）或较低优先级的 Best-effort Class：

#include <sys/syscall.h>
#include <unistd.h>

// 将当前线程（Compaction 线程）的 I/O 优先级设为最低
void SetCompactionIOPriority() {
    pid_t tid = syscall(SYS_gettid);
    // IOPRIO_CLASS_IDLE: 优先级为 3
    syscall(SYS_ioprio_set, 1, tid, (3 << 13)); 
}

同时，结合 cgroups v2 的 io.max 和 io.weight 限制，可以在容器化部署时，提供多一层底层的硬性安全兜底。

六、 生产环境的最佳落地实践（RocksDB 配置调优指南）

如果你使用的是基于 RocksDB 的存储引擎，可以通过以下关键参数的组合配置，在生产环境中落地上述设计思想：

总结

在 LSM-Tree 存储引擎的设计中，防击穿 P99 延迟的本质是在“后台 Compaction 进度”与“前台 I/O 吞吐”之间寻找一种动态的、高灵敏度的微积分平衡。

通过构建多级优先级令牌桶提供业务感知，利用反馈控制算法实现自适应速限，通过线程局部缓存消除锁竞争，最后配合 Direct I/O 穿透内核屏障，才能真正驯服 Compaction 这头 I/O 怪兽，让你的存储系统在高并发写入下依然保持如丝般顺滑的超低尾部延迟。