为什么你的 RocksDB 几乎从不走零拷贝？C++ 存储引擎写放大排查深度指南

在以单调递增主键为主的写入场景中，理论上新生成的 SSTable 与深层数据少有键重叠，后台归并理应以极低的代价推进。然而在线上维护 RocksDB 时，经常能看到磁盘 I/O 持续跑满、写放大居高不下的情况——即便业务写入在逻辑上完全有序，落到存储引擎底层，每一次跨层压实依然在频繁触发全量物理重写。

很多工程师在排查这类写放大问题时，通常会关注“零拷贝搬移”（Trivial Move）。直觉上，如果某个待归并的文件在目标层没有重叠范围，只需在元数据清单中修改指针将其沉入下层，便能省去整盘物理读写，该步写放大也直接归零。但现实往往不如人意：不仅零拷贝搬移的触发概率远低于预期，甚至在尝试调整归并候选优先级（compaction_pri）试图换取更低写放大时，又常会意外引发“墓碑长期无法回收、读性能崩塌”的次生问题。

零拷贝搬移绝非单纯的“无重叠即放行”，而是一套受到层级拓扑、祖父层重叠、存储介质路径与压缩算法严密约束的防御性机制；同层候选文件的选取，更是在写放大、空间回收时效与并发吞吐之间的工程权衡。本文结合 RocksDB 内核源码与实际调优经验，系统梳理 IsTrivialMove 的判定树、批量扩展机制，以及五种 compaction_pri 策略的设计动机与线上隐患。

1. 写放大困局与零拷贝搬移的底层诉求

1.1 LSM-Tree 的物理账本与写放大

要厘清零拷贝搬移的价值，需先审视 Leveled Compaction 模型下的 I/O 放大逻辑。RocksDB 官方将写放大（Write Amplification, WA）定义为：

$$\\text{WA} = \\frac{\\text{磁盘实际写入物理字节数}}{\\text{用户前台写入业务字节数}}$$

为保障高吞吐的写入能力，写入请求通常先追加至预写日志（WAL），并在内存中的 MemTable 维护跳表结构。当 MemTable 写满后冻结并通过后台 Flush 线程顺序落盘为 Level 0（L0）的 SSTable 文件。由于各 L0 文件的键范围完全取决于 MemTable 冻结时的内存状态，因此 L0 文件间的键范围天然存在大量重叠。为了回收历史多版本、清理 Delete 产生的墓碑（Tombstone），并确保从 L1 开始各层内部键范围严格全局递增且互不重叠，后台 Compaction 必须持续运行。

在经典 Leveled Compaction 中，L1 及以上各层的容量通常呈几何级数放大（默认放大因子为 10）。假设 L1 容量上限为 10 MB，则 L2 为 100 MB，L3 为 1 GB，依此类推。当某层总容量超标时，调度器会从该层选出候选文件，并在目标层找出所有键范围相交的文件，共同拉入内存执行多路归并排序，重新切分为新的 SSTable 写回目标层。

这一过程的物理 I/O 账本极为敏感：若在 L1 选中一个 10 MB 的文件，而它在 L2 中与 10 个文件相交（对应约 100 MB 数据），为了将这 10 MB 数据推进到 L2，后台需要从磁盘读取 110 MB 数据，经过 CPU 比较解压过滤后，再向磁盘写入 110 MB 的新文件。仅这一步跨层归并，局部写放大就达到了 11 倍。数据从 L0 最终下沉到 L6 的全链路累积写放大，在线上往往高达 20 至 40 倍。

高写放大不仅会大幅加速闪存介质的磨损，更会因争抢磁盘带宽与 CPU 周期，导致前台读写请求出现严重的毛刺和排队超时。若前台写入速率持续压制后台归并速率，L0 文件堆积还会进一步触发 Write Stall，迫使客户端请求被限流甚至阻塞挂起。

1.2 状态整理与机械重写的矛盾

在物理 I/O 极其敏感的场景下，后台归并承担着两个互相制衡的职责：

此时若依然启动多路归并迭代器，对数据块逐一解压、复制、重新计算 Checksum、重建布隆过滤器并重新写盘，实际上并未清理任何垃圾数据，仅仅是将该 SSTable 在逻辑层级上向下推进了一层，却徒增了数十至数百兆字节的磁盘 I/O 开销。

1.3 零拷贝搬移（Trivial Move）的本质：元数据指针跃迁

零拷贝搬移 IsTrivialMove 便是专门用于避免上述机械重写的优化路径。

所谓零拷贝，指该次 Compaction 不对磁盘上的底层 SSTable 文件进行任何物理读取、解析与重新编码。其全部开销，仅是在 MANIFEST 清单中追加一条版本变更记录（VersionEdit）：从源层注销该文件元数据，并在目标层重新登记该文件，随后在内存中发布新的版本快照。

在 RocksDB 源码 db/db_impl/db_impl_compaction_flush.cc 中，DBImpl::PrepareTrivialMoveEdit 展现了这一过程的底层实现：

C++

void DBImpl::PrepareTrivialMoveEdit(Compaction& c, LogBuffer* log_buffer,
size_t& moved_files, size_t& moved_bytes) {
mutex_.AssertHeld();

ROCKS_LOG_BUFFER(log_buffer, "[%s] Moving %d files to level-%d\\n",
c.column_family_data()->GetName().c_str(),
static_cast<int>(c.num_input_files(0)), c.output_level());

// 仅向 VersionEdit 写入元数据变更，实现文件跨层移动
for (unsigned int l = 0; l < c.num_input_levels(); l++) {
if (c.level(l) == c.output_level()) {
continue;
}
for (size_t i = 0; i < c.num_input_files(l); i++) {
FileMetaData* f = c.input(l, i);
// 1. 在源层标记注销该文件
c.edit()->DeleteFile(c.level(l), f->fd.GetNumber());
// 2. 在目标层以原有物理属性重新登记该文件
c.edit()->AddFile(
c.output_level(), f->fd.GetNumber(), f->fd.GetPathId(),
f->fd.GetFileSize(), f->smallest, f->largest, f->fd.smallest_seqno,
f->fd.largest_seqno, f->marked_for_compaction, f->temperature,
f->oldest_blob_file_number, f->oldest_ancester_time,
f->file_creation_time, f->epoch_number, f->file_checksum,
f->file_checksum_func_name, f->unique_id,
f->compensated_range_deletion_size, f->tail_size,
f->user_defined_timestamps_persisted, f->min_timestamp,
f->max_timestamp, f->file_open_metadata);
moved_bytes += static_cast<size_t>(c.input(l, i)->fd.GetFileSize());
}
moved_files += c.num_input_files(l);
}
}

在整个函数中，没有任何涉及底层文件的 I/O 读写调用。核心操作仅包含：

这两个操作被打包写入 MANIFEST，并在内存中更新版本映射。对于一个 64 MB 的 SST 文件，原本需要数百毫秒的物理读写与大量 I/O 资源，在 Trivial Move 路径下被缩减为几十微秒级别的单次元数据日志提交。

1.4 典型直觉误区：键范围无交集即能零拷贝？

许多工程师常抱有一个直觉假设：只要源层选中的文件在目标层没有键交叠，系统就必然走零拷贝通道。

这一心智模型并不成立，也是导致很多线上实例“预期能零拷贝却频遭全量重写”的技术疑惑根源。在 RocksDB 内部，即便目标层完全没有相交数据，调度器仍有大概率否决零拷贝，强制将其送入常规重写流程。其背后原因通常涵盖：

• 将该文件下沉至目标层后，是否会导致在未来与祖父层产生不可控的超大重叠？

• 实例是否配置了多磁盘路径（db_paths），导致源文件物理存储卷与目标层设定卷不一致？

• 各层级之间是否配置了不同的压缩算法（CompressionType）？

• 是否注册了必须逐条执行校验的 CompactionFilter？

• 是否配置了按前缀切割的 SstPartitioner 并跨越了分割线？

零拷贝搬移必须满足一组互为前置的防御性约束。

2. 零拷贝搬移的内核判定树（Compaction::IsTrivialMove）

2.1 调度入口：LevelCompactionBuilder 的决策链路

分层归并的任务组装由 LevelCompactionPicker 及其内部辅助类 LevelCompactionBuilder 主导（代码位于 db/compaction/compaction_picker_level.cc 中的 PickCompaction()）。其核心流程如下：

2.2 四大基础硬性门槛

在 db/compaction/compaction.cc 中，Compaction::IsTrivialMove() 构成了跳过物理重写的第一道门禁。要满足零拷贝，首先必须严格符合以下四项基本条件：

C++

if (!(start_level_ != output_level_ && num_input_levels() == 1 &&
input(0, 0)->fd.GetPathId() == output_path_id() &&
InputCompressionMatchesOutput())) {
return false;
}

门槛一：目标层必须绝对无相交输入（num_input_levels() == 1）

在 RocksDB 的设计中，常规跨层归并的输入层级数量 num_input_levels() 为 2：索引 0 代表源层输入文件，索引 1 代表目标层被拉入的重叠文件。仅当目标层检索到的相交文件集合为空时，输入结构才不会推入第二层数据，此时 num_input_levels() 才为 1。哪怕目标层仅有一个文件与输入文件存在单个键的边缘重合，该文件也会被拉入输入集，导致 num_input_levels() 变为 2，零拷贝当即终止。

门槛二：L0 层的全局无重叠前提

如果源层为 L0，情况更为严苛。常规写入下 L0 文件互相交叠，若从 L0 挑出文件 A（在 L1 无重叠），但 L0 中存在刷盘更早的文件 B 且 B 与 A 的键范围存在交集。若强行把 A 挪入 L1 而将 B 留在 L0，由于读查询永远先查 L0 再查 L1，会导致版本可见性被颠倒，产生脏读或已删数据复活。

因此源码在函数开头设置了防御门禁：

C++

if (start_level_ == 0 && input_vstorage_->level0_non_overlapping() == false &&
l0_files_might_overlap_) {
return false;
}

只有整个 L0 已经过验证互不重叠，或者本次选出的文件集能自证在 L0 内完全独立，L0 才能走零拷贝。常规写入负载下，L0 到 L1 的归并几乎均需物理重写。

门槛三：物理存储卷与路径一致性（Path ID 匹配）

判定式中的 input(0, 0)->fd.GetPathId() == output_path_id() 对应多磁盘存储拓扑（db_paths）。若浅层挂载在高速 NVMe 固态硬盘（Path 0），而深层位于大容量机械盘或网络存储（Path 1），在操作系统层面不可能仅通过修改元数据跨物理卷移动文件。一旦 Path ID 不匹配，必须走物理数据复制通道。

门槛四：层间压缩算法一致性（InputCompressionMatchesOutput）

若各层配置了阶梯式压缩策略（例如浅层使用轻量 LZ4 或不压缩以降低 CPU 开销，深层使用高压缩比 ZSTD 降低存储成本），当 L2 文件尝试移动至 L3 时，即便目标层完全无冲突，InputCompressionMatchesOutput() 也会直接返回 false。因为放行零拷贝会导致未压缩或轻量压缩的数据直接落入高压缩比层，破坏了该层的存储密度预期。系统宁可耗费 I/O 进行转码重写，也绝不破坏分层压缩一致性。

2.3 规避级联灾难：祖父层（Grandparent）重叠约束

即便前述四个基础门槛全部通过，依然不能直接执行零拷贝。在 db/compaction/compaction.cc 中，存在一段关键的防御性逻辑——祖父层重叠体积检查：

C++

if (output_level_ + 1 < number_levels_) {
std::unique_ptr<SstPartitioner> partitioner = CreateSstPartitioner();
for (const auto& file : inputs_.front().files) {
std::vector<FileMetaData*> file_grand_parents;
// 获取输入文件在祖父层（output_level_ + 1）中的相交文件列表
input_vstorage_->GetOverlappingInputs(output_level_ + 1, &file->smallest,
&file->largest,
&file_grand_parents);
const auto compaction_size =
file->fd.GetFileSize() + TotalFileSize(file_grand_parents);
// 若与祖父层重叠的总数据量超过 max_compaction_bytes，一票否决！
if (compaction_size > max_compaction_bytes_) {
return false;
}

if (partitioner.get() != nullptr) {
if (!partitioner->CanDoTrivialMove(file->smallest.user_key(),
file->largest.user_key())) {
return false;
}
}
}
}

为什么需要探查更深一层的祖父层？

假设当前待归并文件位于 L2，大小为 64 MB；目标层 L3 在对应键范围完全为空，看似是完美的零拷贝场景。然而，调度器顺着键范围向深层的 L4（即当前归并的祖父层）检索时，发现该键区间在 L4 存在密集的已有数据，文件总计达到数十个、累计大小超过 1 GB。

若此时放行零拷贝，这颗 64 MB 的文件将被直接空投到 L3。由于其键跨度很大，在未来该文件从 L3 触发下沉时，必须将 L4 这超过 1 GB 的数据全部卷入同一场归并任务，瞬间引爆超大型 Compaction，严重阻塞后台并恶化前台延迟。

相反，若在 L2 阶段拒绝零拷贝并执行常规归并，后台排序重写会将这 64 MB 数据合理切细为符合 L3 规格的更小粒度文件。后续这些细粒度文件独立向下归并时，每次与 L4 碰撞的数据量均处于可控范围。

通过 compaction_size > max_compaction_bytes_ 实施拦截，本质上是用浅层一次可控的物理重写，避免在深层引爆失控的级联归并风暴。

2.4 其他硬性否决约束（SstPartitioner、PerKeyPlacement 等）

在更复杂的部署场景中，还存在以下几类直接否决零拷贝的规则：

• SstPartitioner 边界约束：若系统配置了分区器用于按特定前缀切分文件，当输入文件的 smallest 与 largest 跨越了分区断点，直接搬移会破坏目标层的物理切分规范。此时 partitioner->CanDoTrivialMove() 返回 false，强制物理重写以便按断点重新拆分文件。

• 按键分层放置（PerKeyPlacement）：该特性允许在单次归并中根据 key 的时效或冷热属性，将部分 key 留在浅层、部分沉入深层。由于这需要细化到单个 KV 记录进行解包分流，与“整文件元数据变更”天然互斥，一旦开启直接禁用零拷贝。

• CompactionFilter 与温度迁移：若配置了必选的 CompactionFilter，由于需要逐条过滤过期记录，或者归并原因为存储温度变更（kChangeTemperature，需在不同介质间重新写入数据块），均会强制执行全量物理归并。

2.5 判定决策拓扑

综合上述约束，RocksDB 判断一次跨层归并能否走零拷贝的完整逻辑如下图所示：

text

[PickCompaction 选出候选文件集]
|
v
[目标层是否有重叠文件?] ———— 是 ————> [走向全量物理重写]
| 否
v
[L0 文件可能存在重叠?] ———— 是 ————> [走向全量物理重写]
| 否
v
[源路径与目标路径一致?] ———— 否 ————> [走向全量物理重写]
| 是
v
[各层压缩算法完全匹配?] ———— 否 ————> [走向全量物理重写]
| 是
v
[祖父层重叠超 max_compaction_bytes?] – 是 ———-> [走向全量物理重写]
| 否
v
[分区器 / Filter / 温度检查通过?] — 否 ————> [走向全量物理重写]
| 是
v
[批准零拷贝搬移 IsTrivialMove]

3. 行为验证：边界重叠与零拷贝触发的对比实验

基于 RocksDB 单元测试套件（CompactionPickerTest），我们可以通过精确构造边界条件来复现零拷贝的触发与退化行为。

3.1 验证环境与参数设置

在测试套件中初始化一个 6 层的 Leveled 存储模型，核心参数如下：

• max_bytes_for_level_base = 1000u（单层容量基准）；

• max_compaction_bytes = 10000001u（放大归并阈值，规避祖父层容量误伤）；

• 统一各层压缩为未压缩，单挂载点单一路径；

• 候选优先级设定为 kMinOverlappingRatio。

3.2 场景 A：无重叠区间的零拷贝与批量下沉

在 L2 构造 8 个连续文件，在 L3 刻意保留 [300, 700] 的真空区间：

C++

TEST_F(CompactionPickerTest, TraceTrivialMoveVerification) {
mutable_cf_options_.max_bytes_for_level_base = 1000u;
mutable_cf_options_.max_compaction_bytes = 10000001u;
ioptions_.level_compaction_dynamic_level_bytes = false;
ioptions_.compaction_pri = kMinOverlappingRatio;
NewVersionStorage(6, kCompactionStyleLevel);

// 在 L2 构造 8 个连续文件，各约 3000 字节
Add(2, 1U, "100", "150", 3000U);
Add(2, 2U, "151", "200", 3001U);
Add(2, 3U, "301", "350", 3000U);
Add(2, 4U, "351", "400", 3000U);
Add(2, 5U, "451", "500", 3000U);
Add(2, 6U, "551", "600", 3000U);
Add(2, 7U, "651", "700", 3000U);
Add(2, 8U, "851", "900", 3000U);

// 在 L3 构造已有文件，注意中间 [300, 700] 区间保持完全真空
Add(3, 15U, "120", "130", 700U); // 与 L2 文件 1 重叠
Add(3, 16U, "170", "180", 700U); // 与 L2 文件 2 重叠
Add(3, 17U, "220", "230", 700U); // 位于间隔区
Add(3, 18U, "870", "880", 700U); // 与 L2 文件 8 重叠

UpdateVersionStorageInfo();

std::unique_ptr<Compaction> compaction(level_compaction_picker.PickCompaction(
cf_name_, mutable_cf_options_, mutable_db_options_,
/*existing_snapshots=*/{}, /* snapshot_checker */ nullptr,
vstorage_.get(), &log_buffer_, /*full_history_ts_low=*/""));

ASSERT_NE(compaction, nullptr);
// 断言一：成功裁定为零拷贝搬移
ASSERT_TRUE(compaction->IsTrivialMove());
// 断言二：目标层无相交文件，输入层数严格为 1
ASSERT_EQ(1, compaction->num_input_levels());
// 断言三：触发批量扩展，一次性打包 4 个文件
ASSERT_EQ(4, compaction->num_input_files(0));
ASSERT_EQ(3, compaction->input(0, 0)->fd.GetNumber());
ASSERT_EQ(4, compaction->input(0, 1)->fd.GetNumber());
ASSERT_EQ(5, compaction->input(0, 2)->fd.GetNumber());
ASSERT_EQ(6, compaction->input(0, 3)->fd.GetNumber());
}

测试断言顺利通过。执行细节表明：

3.3 场景 B：注入微量交集导致退化为全量归并

在场景 A 的基础上，我们仅向 L3 原本真空的区间注入一个仅 100 字节的微型文件，其余数据保持不变：

C++

// 仅在 L3 插入一个 100 字节的小文件，范围为 [340, 345]
Add(3, 99U, "340", "345", 100U);
UpdateVersionStorageInfo();

std::unique_ptr<Compaction> compaction(level_compaction_picker.PickCompaction(
cf_name_, mutable_cf_options_, mutable_db_options_,
/*existing_snapshots=*/{}, /* snapshot_checker */ nullptr,
vstorage_.get(), &log_buffer_, /*full_history_ts_low=*/""));

ASSERT_NE(compaction, nullptr);
// 零拷贝条件被完全破坏
ASSERT_FALSE(compaction->IsTrivialMove());
// 输入层级数变为 2
ASSERT_EQ(2, compaction->num_input_levels());

运行结果显示 compaction->IsTrivialMove() 立即返回 false。

这是因为文件 99 的键区间 [340, 345] 恰好嵌入了 L2 文件 3 的范围 [301, 350] 内。即便只有 100 字节，调度器在拉取目标层重叠时也必须把文件 99 纳入输入集：

• num_input_levels() 从 1 变为 2；

• 后台线程必须完整读入 L2 文件 3（3000 字节）与 L3 文件 99（100 字节）；

• 经由多路迭代器重新排序比对，重新写出 3100 字节的新文件。

微小的重叠边界打破了真空区间，使原本几十微秒的元数据修改直接退化为了全量磁盘物理 I/O。

3.4 批量搬移的扩展边界：TryExtendNonL0TrivialMove

在场景 A 中，文件 3 至 7 在 L3 均无重叠，但最终只打包了 4 个文件。这是由 TryExtendNonL0TrivialMove（位于 compaction_picker_level.cc）中的硬编码上限决定的：

C++

const size_t kMaxMultiTrivialMove = 4;
// …
for (int i = start_index + 1;
i < static_cast<int>(level_files.size()) &&
start_level_inputs_.size() < kMaxMultiTrivialMove;
i++) {
FileMetaData* next_file = level_files[i];
if (next_file->being_compacted) {
break; // 相邻文件若被其他归并线程占用，立即终止扩展
}
// 校验扩展后的总键范围在目标层是否依然无交叠
vstorage_->GetOverlappingInputs(output_level_, &(initial_file->smallest),
&(next_file->largest),
&output_level_inputs.files);
if (!output_level_inputs.empty()) {
break; // 一旦发现重叠，立即停止
}
// 累加大小不得超过 max_compaction_bytes
total_size += next_file->fd.GetFileSize();
if (total_size > mutable_cf_options_.max_compaction_bytes) {
break;
}
start_level_inputs_.files.push_back(next_file);
}

单次最多扩展 4 个文件的限制，是为了防止一次性将过宽键区间的连续文件集体下沉，避免在目标层形成大面积的连续文件带，从而加大该区间与更深层级发生并发冲突与超大归并的概率。

4. 零拷贝搬移的系统性代价：写放大的局部收益与全局负债

4.1 局部写放大归零与理论收益

在 Leveled Compaction 架构中，全库的总写放大理论上是各层局部写放大的累加：

$$\\text{WA}{\\text{total}} \\approx 1 + \\sum{i=0}^{N-1} \\text{WA}{L_i \\to L{i+1}}$$

若单次跨层压实满足了零拷贝搬移，由于写入磁盘物理字节数为 0，这一步的局部写放大直接为 0。

若单调递增的批次数据能够在浅层连续触发 Trivial Move 并顺利滑落至深层，浅层写放大将被完全抹平，只有当它最终在深层碰撞到存量数据时才开始消耗物理 I/O。

4.2 隐性成本：墓碑滞留与读路径长尾抖动

然而，零拷贝搬移并不适用于所有场景，它本质上是用“空间利用率下降”与“读性能折损”换取写入吞吐的短平快手段：

成本一：Delete 墓碑与失效版本的深度滞留

物理归并的核心功能是垃圾回收。当上层产生 Delete 操作时，底层仅是写入一条墓碑记录。要彻底抹除记录并释放磁盘空间，必须通过物理归并将其与深层旧版本数据对齐消除。

零拷贝搬移完全不触碰 SSTable 数据块。若包含大量墓碑的文件频繁执行零拷贝，这些墓碑将原封不动地沉入深层。更严重的是，源层被覆盖写的旧版本数据也无法被剔除，导致磁盘空间长期无法释放，空间放大（Space Amplification）显著恶化。

成本二：碎片化文件破坏查询与扫描性能

在点查与范围遍历中，布隆过滤器与迭代器的执行开销高度依赖于各层文件的平均尺寸与分布致密性。

常规物理归并会将零散数据重新组装为符合预设大小（例如 64 MB）的规范 SSTable。但零拷贝搬移会将浅层尺寸偏小（如刚 Flush 出的细碎文件）直接原样挂载到深层，导致深层文件数量暴增、键范围高度碎片化。在执行范围扫描时，迭代器必须在深层归并更多小文件的堆顶，增加 CPU Cache Miss；而沿途未被清理的大量墓碑也会迫使扫描线程执行大量无意义的跳跃迭代，引发长尾读延迟抖动。

5. 同层候选文件调度：五大 compaction_pri 算法演进

当某一层的总数据量超标触发 Compaction，但同层存在多个候选文件时，调度器如何决定优先选取哪一个？这就是配置参数 compaction_pri 的核心职责。

5.1 历史演进：LevelDB 单游标轮转的并发缺陷

在 LevelDB 中，同层文件的选择相对粗糙：系统在内存中为每一层记录一个持久游标（compact_pointer_）。每次归并完成后，游标推进到刚才被归并文件的最大键处。下次触发归并时，直接沿着游标位置后移选取下一个文件。

在单线程归并的时代，这种全局轮转能保证各键区间被均匀压实。但进入多线程并发归并后，单游标轮转暴露出明显缺陷：

• 严重的并发锁冲突：多个工作线程同时获取游标附近的相邻文件，导致并发归并任务极易因键范围交叠而互相阻塞；

• 无视数据冷热倾斜：现实中写入往往不均匀，盲目轮转会导致冷数据区间被频繁调度，浪费 I/O 吞吐；

• 无法对写放大实施精细调优：不同文件的目标层重叠度差异巨大，机械按游标选择容易撞上重叠巨大的文件。

RocksDB 为此重构了调度框架，提供了基于多维指标的候选优先级机制。

5.2 驱动写放大的三个关键变量

官方在《Option of Compaction Priority》架构分析中指出了影响写放大的三大关键变量：

基于以上考量，RocksDB 在 include/rocksdb/advanced_options.h 中定义了 5 种候选优先级：

C++

enum CompactionPri : char {
kByCompensatedSize = 0x0, // 按补偿大小降序（优先清理大文件或墓碑多的文件）
kOldestLargestSeqFirst = 0x1, // 最旧的最大序列号优先（冷数据下沉，热数据留浅层）
kOldestSmallestSeqFirst = 0x2, // 最旧的最小序列号优先（防饥饿，均衡压实）
kMinOverlappingRatio = 0x3, // 下层最小重叠比优先（极致优化写放大）
kRoundRobin = 0x4, // 现代化大跨度轮转
};

5.3 五种候选优先级策略实现剖析

策略枚举

排序核心依据

优点

潜在缺陷

适用负载

深入剖析 kMinOverlappingRatio 的排序逻辑

在 db/version_set.cc 的 SortFileByOverlappingRatio 中，最小重叠比策略展现了具体的打分机制：

C++

void SortFileByOverlappingRatio(…) {
// …
for (auto& file : files) {
uint64_t overlapping_bytes = 0;
// 快速计算当前文件在目标层相交的数据总字节
// …
uint64_t ttl_boost_score = (ttl > 0) ? ttl_booster.GetBoostScore(file) : 1;

// 核心评分公式：Score 越小，优先级越高！
file_to_order[file->fd.GetNumber()] = overlapping_bytes * 1024U /
file->compensated_file_size /
ttl_boost_score;
}

// 依据评分做局部排序
std::partial_sort(
temp->begin(), temp->begin() + num_to_sort, temp->end(),
[&](const Fsize& f1, const Fsize& f2) -> bool {
// 先按 marked_for_compaction 排序，再按计算出的 Score 升序排列
// …
});
}

其评分公式为：

$$\\text{Score} = \\frac{\\text{OverlappingBytes} \\times 1024}{\\text{CompensatedFileSize} \\times \\text{TTLBoostScore}}$$

• 分母为文件自身的有效体积及 TTL 提权系数；

• 分子为该文件在目标层的重叠字节数。

• 当文件在目标层无任何相交数据时，OverlappingBytes = 0，计算出的 Score 精确为 0，直接排在候选队列最前端，优先尝试零拷贝下沉。

• 当两个文件的目标层重叠均为 0 时，系统按键顺序排序，使无重叠的相邻文件聚集在一起，便于后续批量打包。

6. 时间维度与并发规避：FileTtlBooster 与运行态锁

6.1 FileTtlBooster：解耦物理体积与提权分值

在 SortFileByOverlappingRatio 的公式分母中，包含一个提权系数 ttl_boost_score。该系数由 FileTtlBooster 计算（位于 db/compaction/file_pri.h）。

在时序数据或配置了 TTL / Periodic Compaction 的场景中，老文件需要定期被归并重写以回收全局过期数据。如果在调度时直接修改文件的 compensated_file_size 强行提权，会干扰分层容量的真实统计，导致 RocksDB 错误地估高层级总数据量并误触 Write Stall。

因此系统引入了独立的提权因子 FileTtlBooster：

C++

class FileTtlBooster {
public:
FileTtlBooster(uint64_t current_time, uint64_t ttl, int num_non_empty_levels,
int level)
: current_time_(current_time) {
if (ttl == 0 || level == 0 || level >= num_non_empty_levels – 1) {
enabled_ = false;
boost_age_start_ = 0;
boost_step_ = 1;
} else {
enabled_ = true;
// 存活时间未满 TTL 的一半前不予提权
uint64_t all_boost_start_age = ttl / 2;
uint64_t all_boost_age_range = (ttl / 32) * 31 – all_boost_start_age;

// 核心算法：通过位移逐层指数级推迟提权起始时间
uint64_t boost_age_range =
all_boost_age_range >> std::min(63, num_non_empty_levels – level – 1);
boost_age_start_ = all_boost_start_age + boost_age_range;
const uint64_t kBoostRatio = 16;
boost_step_ = std::max(boost_age_range / kBoostRatio, uint64_t{1});
}
}

uint64_t GetBoostScore(FileMetaData* f) {
if (!enabled_) return 1;
uint64_t oldest_ancester_time = f->TryGetOldestAncesterTime();
if (oldest_ancester_time >= current_time_) return 1;
uint64_t age = current_time_ – oldest_ancester_time;
if (age > boost_age_start_) {
return (age – boost_age_start_) / boost_step_ + 1;
}
return 1;
}
};

6.2 分层指数错峰：消除级联归并共振

请注意这行通过位移计算提权窗口的代码：

C++

uint64_t boost_age_range =
all_boost_age_range >> std::min(63, num_non_empty_levels – level – 1);

若各层快到期的文件在同一时刻开始提权下沉，会瞬间触发全层级并发冲突：L1 强制落入 L2，L2 瞬间容量超标又被迫向下压实，引发全库级联归并共振，前台吞吐将出现严重断崖。

RocksDB 采用按层指数错峰机制：

• 浅层文件的 boost_age_start_ 相对靠前，优先在浅层完成下沉消化；

• 越往深层，提权起始时间被推迟得越晚，提权步长被压缩得越窄。

通过在时间轴上将到期文件的提权触发点指数级错开，系统平滑化解了集中到期引发的级联毛刺。

6.3 并发归并下的运行态冲突避让

在多线程并发调度下，选出的文件还必须经过运行态互斥校验（FilesRangeOverlapWithCompaction，位于 db/compaction/compaction_picker.cc）。候选文件即便综合得分极高，若出现以下任一情况也会被直接跳过：

7. 优先级错配引发的线上隐患：kMinOverlappingRatio 与墓碑饥饿

7.1 典型失效场景：海量 Delete 标记遭遇永久饥饿

在实际运维中，部分团队为了压低写放大，常将生产环境的 compaction_pri 全局指定为 kMinOverlappingRatio。若业务伴随定期的历史数据清理，这极易引发严重的系统次生灾害。

设想如下业务模式：系统白天持续单调递增写入，而每日凌晨的清理任务会对某个月前的历史数据执行大批量 Delete，产生千万量级的删除墓碑。

业务预期这批墓碑能尽快随后台归并清除，以释放磁盘容量。但在 kMinOverlappingRatio 策略下，调度器出现了严重的决策偏差：

text

[历史数据聚集文件 X (包含海量墓碑)]
|
|–> 由于属于存量历史区间，在目标层与 10 个老文件重叠 (重叠体积巨大)
|–> Score = (大体积重叠) / (补偿体积) ==> 计算得分极高 (排在队尾)

[边缘新增数据文件 Y (常规小数据)]
|
|–> 属于新增离散区间，在目标层重叠为 0
|–> Score = 0 / (体积) = 0 ==> 计算得分极低 (排在队头，优先调度)

调度器始终认为归并文件 X 的“性价比极低”，因为需要重写庞大的目标层数据；相比之下，两侧无重叠的新增文件总是优先被调度。

其直接后果是：

在存在周期性批量删除的场景中，不能单纯依赖最小重叠比，应采用优先清理墓碑的 kByCompensatedSize，或配合 periodic_compaction_seconds 强制打破长尾饥饿。

7.2 TTL 强行提权对写入水位的冲击

类似情况也会在 FileTtlBooster 提权阶段显现。当某个深层老文件到达提权阈值后，其分母迅速膨胀，导致其评分强行跃升至队列前列。系统可能被迫发起一场与下层产生大量重叠的高开销 Compaction。此时若前台写入处于峰值，后台归并吞吐被该重型任务占用，可能引发阶段性的 Flush 延迟与写入停顿。

7.3 典型负载下的优先级选型矩阵

针对不同的业务负载特征，归并候选优先级的选型建议如下：

text

业务负载特征 推荐优先级 核心收益与考量
—————————————————————————————————-
时序 / 日志单调递增写入 kMinOverlappingRatio 充分利用键空间真空区，最大化零拷贝，写放大最低
小工作集 / 局部高频热点更新 kOldestLargestSeqFirst 冷数据逐步沉底，热点保留在浅层吸收覆盖写
全键空间均匀随机离散写入 kOldestSmallestSeqFirst 避免局部键空间饥饿，保障全库均衡推进
包含大规模集中删除 (Tombstone) kByCompensatedSize 补偿体积将墓碑权重放大，优先清除死数据释放空间
稳定吞吐 / 规避并发冲突扰动 kRoundRobin 大跨度均匀轮转，平滑单次归并峰值，吞吐平稳

8. 观测体系与线上排查手册

8.1 指标口径辨析：文件数比例 vs 字节数比例

在分析优化成效时，偶见类似评估：“系统经过调整后，零拷贝搬移占比达到了 80%。”

对此必须明确指标统计口径的差异。在评估实际写放大减免效果时，文件数口径与字节数口径有着本质区别：

• 文件数口径：$\\frac{\\text{零拷贝搬移的文件数}}{\\text{总处理文件数}}$

• 字节数口径：$\\frac{\\text{零拷贝搬移的物理字节数}}{\\text{总处理物理字节数}}$

设想以下场景：某周期内系统执行了 9 次轻量文件的零拷贝搬移，总计搬移 9 个文件、累计 36 MB 数据，产生 0 物理写入；但在此期间，深层执行了 1 次常规重写，将一个 64 MB 文件与下层多个文件合并，产生了 1 GB 的物理写入。

此时：

• 从文件数口径看，零拷贝占比高达 $90$；

• 从字节数口径看，实际免除重写的字节比例仅占约 $3.4$。

对闪存寿命和 I/O 争抢起决定作用的是落盘的物理字节总量。评估调优成效必须以真实的字节量指标为基准，避免被虚高的文件数占比所误导。

8.2 运行时监控：InternalStats 与事件日志

RocksDB 提供了多层次的运行时监控机制（位于 db/internal_stats.cc）：

途径一：InternalStats 分层状态表

在 RocksDB 的运行日志（LOG）中，定时打印的层级统计表直观展示了物理读写与搬移的水位：

text

Level Read(GB) Write(GB) Moved(GB) W-Amp
————————————————-
L1 1.2 1.2 0.0 6.0
L2 2.4 2.3 1.5 7.6
L3 0.0 0.0 3.2 0.0

• Write(GB)：该层向下归并时向磁盘写入的物理字节量；

• Moved(GB)：通过零拷贝搬移下沉的真实字节量。

若某层的 Moved(GB) 显著大于 Write(GB)，表明该层正高效利用零拷贝下沉数据；反之若为 0，则需审视重叠或前置门禁状态。

途径二：EventListener 结构化事件捕获

注册 EventListener 能够精确捕获每次零拷贝提交事件：

JSON

{
"job": 42,
"event": "trivial_move",
"destination_level": 3,
"files": 4,
"total_files_size": 125829120
}

通过解析 total_files_size 与常规写入事件累加比对，可绘制出生产环境中精确的真实搬移字节比率曲线。

8.3 零拷贝未生效的排查流程

当业务具备单调顺序写入特征，但监控中 Moved(GB) 长期偏低时，可依序排查以下 5 个关键点：

text

[排查顺序与核对项]
│
├─ 1. 核对各层压缩算法配置 (CompressionType)
│ └─ 浅层与深层压缩算法不一致将直接一票否决
│
├─ 2. 检查多磁盘存储路径 (db_paths)
│ └─ 源文件与目标层预设 Path ID 不一致无法元数据移动
│
├─ 3. 检查 max_compaction_bytes 阈值
│ └─ 阈值过小易导致祖父层重叠体积超标触发防爆盾拦截
│
├─ 4. 检查 compaction_pri 候选策略
│ └─ 选错策略会导致挑出的文件在目标层相交概率偏高
│
└─ 5. 检查客户端写入顺序性与时钟回拨
└─ 微小的客户端时钟乱序会导致新数据在目标层出现局部交错

9. 总结

在分布式存储引擎的工业实现中，没有脱离约束的绝对优化。零拷贝搬移与候选优先级调度的核心工程逻辑可总结为以下三点：