Todis中分布式Compact是怎么工作的？

你看到的 Todis(外存版 Redis) 性能优势，主要来自底层的 ToplingDB 存储引擎！

ToplingDB fork 自 RocksDB，增加了很多改进，也修改了不少 bug，其中有几十个修改也给上游 RocksDB 发了 Pull Request。
目前 Todis 仍在邀请内测中，可通过7分钟视频教程快速开始

ToplingDB 相对于 RocksDB 做了很多改进，不过题主问的是分布式 Compact，那么我们就略过其它，详细聊聊分布式 Compact：

分布式 Compact 客户端

：Todis 服务实例

在 Todis 服务实例中，当发起 L2 及更深层 Compact 时，在 ToplingDB 中：

Status CompactionJob::Run() {
auto icf_opt = compact_->compaction->immutable_options();
auto exec = icf_opt->compaction_executor_factory.get();
if (!exec || exec->ShouldRunLocal(compact_->compaction)) {
return RunLocal();
}
Status s = RunRemote();
if (!s.ok()) {
if (exec->AllowFallbackToLocal()) {
s = RunLocal();
} else {
// fatal, rocksdb does not handle compact errors properly
}
}
return s;
}


ToplingDB 保持 CompactionJob::Run 入口函数名不变，将 原版 RocksDB 的 Run 重命名为 RunLocal，在 Run 中，通过一系列判断决策，看是跑本地，还是远程（分布式 Compact）。

以这样的方式修改代码，RocksDB 中现有的使用 CompactionJob::Run 的代码无需改动，从而将修改局限在 CompactionJob 中。

在 CompactionJob::RunRemote 中，本质上就是一个 RPC 远程调用，但是该远程调用是纯手撸的，没有使用专门的 RPC 框架（例如 GRPC），因为我们就这一处 RPC，犯不着引入一个专用 RPC，额外的好处是可以精准控制 RPC 的每一步逻辑，从而只在 RunRemote 中执行关键步骤，而把详细实现放在一个第三方类库中(私有库 topling-rocks，见 分布式 Compact 文档)。

理论上，社区用户可以将 RocksDB 自身的 CompactionService 封装为 ToplingDB CompactionExecutorFactory 的一个派生类，从而提供另外一种实现方式。

分布式 Compact 服务端：dcompact_worker

dcompact_worker 是一个通用的 compact worker 二进制可执行程序，得益于 ToplingDB 的 SidePlugin 体系，用户只需要通过 LD_PRELOAD 加载自己的组件模块

例如在 todis 中就是 libblackwidow.so，因为 dcompact_worker 会用到 blackwidow 中面定义的各种 CompactionFilterFactory

以这样的方式，大大减小了分布式 Compact 开发与集成的工作量（对比 RocksDB 的 Remote Compaction (Experimental)）。

dcompact_worker 工作流程

我们将 dcompact_worker 实现为一个 http service：

1. 通过 HTTP post 方法，获取 compact 的元信息(例如 db 实例 id, job_id 等)
2. 去共享存储读取 compact 的详细信息
1. input file 列表等……
2. 带状态的 CompactionFilter, MergeOperator, EventListener ……
3. 使用 compact 的详细信息，创建一个 Version 对象
4. 执行 compact
5. 将 compact 详细结果写回共享存储，包括 output file list，CompactionFilter 等状态信息，compact 过程中收集到的 statistic……

作为离线计算，大部分 compact 执行时间都很短（P99 大约 10秒），但仍有少部分 compact 执行时间较长，所以，我们不能 hold 住 http post 方法，直到 compact 执行完再返回，万一 http 连接被断开，在客户端(Todis结点)看来，这个 compact 就相当于失败了。

其实我们一开始使用的是 ETCD，将它的 notify 机制，作为一个“可靠的长连接”来使用，从而简化问题。在我们自己的 100G infiniband 网络中，ETCD 工作得非常好！
然而，当我们真正部署到阿里云上时，因为是公有云，并且要做多租户共享 Compact 集群，所以需要通过公网来传递 compact 元信息和详细信息（不包括 sst 文件内容），从而就必须使用 TLS 加密传输，这时候碰到了 etcd-cpp-apiv3 两个 bug！
我们轻视了这两个 bug，在这上面耗费了大量时间，修复了一个 bug，另外一个 bug，就连 etcd-cpp-apiv3 的作者也表示他也不知道那是什么原因，自然也没有办法修复！
后来不得已才重新设计，使用 http post，通过公网反向代理将转发 compact 请求，实现了多租户共享分布式 compact 功能。

在 http post 中执行的操作非常少，主要是验证 compact 参数，通过后就将 compact 任务放入队列，然后就立即返回。队列中的 compact 任务由一个线程池来执行。

大体流程就是这些，更多的，是工程实现中各种繁琐的细节处理……

目前 Todis 仍在邀请内测中，可通过7分钟视频教程快速开始。