你看到的 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:
- 通过 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 任务由一个线程池来执行。
大体流程就是这些,更多的,是工程实现中各种繁琐的细节处理……
目前 Todis 仍在 邀请内测中,可通过 7分钟视频教程快速开始。