搞定 RocksDB FIFO Compaction 的暗坑：如何在高吞吐下兼顾空间放大与写入抖动？

在分布式存储系统的设计中，针对时序数据、大容量缓存或纯追加（Append-only）写入场景，开发者通常会首选 RocksDB 的 FIFO Compaction 策略。其核心逻辑非常简单：像一个环形缓冲区（Ring Buffer）一样，当 SST 文件总大小超过阈值时，直接删掉最老的文件。

由于没有 Level 间频繁的 Merge-Sort，FIFO 拥有极低的写入放大（Write Amplification Factor, WAF），能极大地释放 SSD 的写入带宽。

然而，在磁盘空间受限且面临持续高吞吐写入的生产环境中，FIFO 策略会暴露出两个极其致命的“双子星”痛点：空间放大（Space Amplification）与写入抖动（Write Jitter）。

本文将深度解构这两个问题在 FIFO 场景下的发生机理，并提供一套可落地的工业级优化方案。

一、 双重压力的根源：为什么 FIFO 扛不住了？

1. 空间放大的黑盒：Tombstone 无法及时清理

FIFO 默认不进行传统意义上的 Compaction（合并与去重）。这意味着：

• Delete 动作失效：当你写入一个 Delete 标记（Tombstone）时，这个 Tombstone 只能存放在最新的 SST 中。只要这个 SST 没有因为“变老”而被 FIFO 彻底丢弃，被删除的历史数据和 Tombstone 就会一直共存，导致严重的空间放大。
• Update 导致的数据冗余：同一个 Key 的多次修改散落在不同的 SST 中，旧版本数据无法被及时清理，白白占用磁盘。

在磁盘空间紧张（如利用率超 80%）时，空间放大可能直接触发分布式系统的磁盘满告警，导致节点只读。

2. 写入抖动的幕后黑手：IO 瞬时过载

虽然 FIFO 避免了 Compaction 的写放大，但它引入了两个新的 IO 瓶颈：

• SSD TRIM 与物理文件删除延迟：当 FIFO 触发文件淘汰时，往往会一次性删除数个甚至数十个 SST 文件（通常每个 256MB 或更大）。在 Linux 下，如果文件系统挂载了 discard 选项，或者底层是云盘（如 AWS EBS、阿里云 ESSD），物理删除大文件会触发密集的 TRIM 操作。这会导致 SSD 内部 GC 瞬间过载，引起严重的 fsync 延迟，导致 RocksDB 的 MemTable 无法及时 Flush，最终触发 Foreground Write Stall。
• MemTable Flush 与磁盘 IO 争抢：在写入极其密集的场景下，即使没有 Compaction，频繁的 MemTable Flush 也会占满 IOPS，与用户的写入操作抢夺物理资源。

二、 深度优化：FIFO Compaction 调优组合拳

要在高吞吐、高空间利用率下驯服 FIFO，必须对其进行“微创手术”。以下四个层面的优化方案缺一不可。

1. 引入局部 Compaction：激活 allow_compaction_on_max_compaction_bytes

纯 FIFO 不做合并，但 RocksDB 允许我们在 FIFO 内部开启一个“局部 Level 0 合并”的后门。

通过开启 allow_compaction_on_max_compaction_bytes，当 L0 文件的总大小或数量达到设定阈值时，RocksDB 会在 L0 内部触发一次轻量级的 Compaction。

rocksdb::CompactionOptionsFIFO fifo_opts;
// 允许在 FIFO 内部针对特定大小的文件进行 Compaction
fifo_opts.allow_compaction_on_max_compaction_bytes = true; 
options.compaction_options_fifo = fifo_opts;

// 配合设置最大合规字节，防止单次 Compaction 过大引起抖动
options.max_compaction_bytes = 2 * 1024 * 1024 * 1024ULL; // 2GB

• 原理：该机制将最活跃的、包含大量 Tombstone 和重复 Update 的新 SST 进行局部合并，提前消灭 Tombstone 并释放空间，极大地缓解了空间放大。
• 代价：会带来轻微的写放大，需要通过压测微调 max_compaction_bytes。

2. 强制回收陈旧 Tombstone：配置 periodic_compaction_seconds

对于那些没有达到删除阈值、但已经存在很久的 SST 文件，我们需要定期对其进行扫描和清理，以防止“长尾空间放大”。

// 强制每隔 12 小时（43200 秒）对老文件进行一次重写，清理其中的 Tombstone
options.periodic_compaction_seconds = 43200; 

• 原理：RocksDB 会在后台对超过此时限未被 Compaction 的文件进行重写。这能确保即使用户写入变慢，历史数据中的 Tombstone 也会被稳步清理，不至于死锁磁盘。

3. 彻底消除删除抖动：启用 delete_scheduler 与异步文件限速

这是解决写入抖动（P99/P999 延迟毛刺）最有效的手段。
千万不要让 RocksDB 线程直接在操作系统中执行 unlink，必须将其托管给 RocksDB 的 Delete Scheduler，进行平滑的异步物理删除。

// 创建一个删除调度器，限制每秒删除文件的最大 IO 带宽（例如 20MB/s）
int64_t rate_bytes_per_sec = 20 * 1024 * 1024; 
std::shared_ptr<rocksdb::SstFileManager> sst_file_manager(
    rocksdb::NewSstFileManager(rocksdb::Env::Default(), nullptr, "", rate_bytes_per_sec)
);
options.sst_file_manager = sst_file_manager;

• 原理：启用后，RocksDB 丢弃 SST 文件时，只是将其重命名为一个临时文件，然后由后台线程以 rate_bytes_per_sec 的速度分块（Truncate）抹除，或者以极低的速度调用系统删除。这能完美避开 SSD 的 TRIM 爆发期，将写入延迟的 P99 曲线拉平。

4. 协同限流：配置全局 RateLimiter 保护 Flush

在极端吞吐下，必须防止后台 Flush 抢占全部 IO。我们需要为 RocksDB 树立一个全局的“交警”。

// 限制 RocksDB 整体后台写速度为 100MB/s，高优先级保证 Flush
std::shared_ptr<rocksdb::RateLimiter> rate_limiter(
    rocksdb::NewGenericRateLimiter(100 * 1024 * 1024, 100 * 1000, 10, rocksdb::RateLimiter::OpType::kWrite)
);
options.rate_limiter = rate_limiter;

配合调大 MemTable 相关参数，防止 Foreground Stall：

options.write_buffer_size = 128 * 1024 * 1024; // 128MB
options.max_write_buffer_number = 6;            // 允许积压更多的 MemTable
options.min_write_buffer_number_to_merge = 2;

三、 架构设计维度的补充：应用层的主动作为

仅仅依靠引擎层参数的微调是不够的，在分布式存储系统的架构设计层面，我们还可以采用以下策略：

1. 放弃 Delete，拥抱 TTL 与 Time-Window Compaction (TWCS)

如果你的业务数据天然带有生命周期（如监控指标、日志、会话缓存），不要在应用层发送 Delete 请求。

• 在 RocksDB 中使用内置的 TTL 功能。
• 或者直接切换到 Time-Window Compaction Strategy (TWCS)。它在 FIFO 的基础上，加入了时间窗口的概念，能更好地保证同一时间段的数据落入同一个 SST，到期直接整组丢弃，零写放大，零空间浪费。

2. 分布式协调：轮询主动触发 Compaction（Rolling Compaction）

在分布式集群中，可以利用主备节点的角色差异。例如，在业务低峰期，通过控制中心向集群中的非活跃副本发送 CompactRange 指令，主动收缩磁盘空间。通过控制并发度，避免影响对外服务的节点。

四、 优化效果对比与总结

在实际的分布式 KV 存储压测中，采用上述优化策略前后的性能对比通常如下：

总结：
FIFO Compaction 绝非“开箱即用、一劳永逸”的万灵药。在高压力的工业级场景下，必须通过 delete_scheduler 解决物理删除带来的 IO 冲击，通过 allow_compaction_on_max_compaction_bytes 与 periodic_compaction_seconds 引入适度的、可控的局部合并来清理垃圾数据。

用少量的写放大（WAF），换取系统长时间运行的稳定性和高磁盘利用率，这是构建高性能分布式存储系统时最经典的折衷艺术。