你看到的Todis(外存版 Redis) 性能优势，主要来自底层的ToplingDB存储引擎！
ToplingDBfork 自 RocksDB，增加了很多改进，也修改了不少 bug，其中有几十个修改也给上游 RocksDB 发了 Pull Request。
目前 Todis 仍在邀请内测中，可通过7分钟视频教程快速开始
ToplingDB 相对于 RocksDB 做了很多改进，不过题主问的是分布式 Compact，那么我们就略过其它，详细聊聊分布式 Compact：
分布式 Compact客户端：Todis 服务实例
在Todis 服务实例中，当发起 L2 及更深层 Compact 时，在 ToplingDB 中：
StatusCompactionJob::Run(){autoicf_opt=compact_->compaction->immutable_options();autoexec=icf_opt->compaction_executor_factory.get();if(!exec||exec->ShouldRunLocal(compact_->compaction)){returnRunLocal();}Statuss=RunRemote();if(!s.ok()){if(exec->AllowFallbackToLocal()){s=RunLocal();}else{// fatal, rocksdb does not handle compact errors properly}}returns;}
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：
通过 HTTP post 方法，获取 compact 的元信息(例如 db 实例 id, job_id 等)
去共享存储读取 compact 的详细信息
input file 列表等……
带状态的 CompactionFilter, MergeOperator, EventListener ……
使用 compact 的详细信息，创建一个 Version 对象
执行 compact
将 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 任务由一个线程池来执行。
大体流程就是这些，更多的，是工程实现中各种繁琐的细节处理……
