Todis from RocksDB to ToplingDB

Todis 从 RocksDB 到 ToplingDB

Todis fork 自 pika, pika 底层存储使用的是 RocksDB，所以，Todis 开发中最主要的工作就是从 RocksDB 迁移到 ToplingDB。

一般而言，从 RocksDB 迁移到 ToplingDB，只需要很小的改动。但是对于 Todis 这样一个真正的产品级数据库，有很多地方，需要从设计上，进行根本性的改动，甚至已经是重新设计了，主要有：

1. 主从机制：我们使用 RocksDB 的 Secondary Instance
2. 使用 ToplingDB 性能组件：更快的 MemTab, 更快的 SST, 压缩的 SST
3. 使用 ToplingDB 分布式 Compact
4. 人性化：增加监控指标，Todis 组件可视化

主从机制：我们使用 RocksDB 的 Secondary Instance

这个在 ToplingDB 中是最简单的，只需要修改配置：使用 DB::OpenAsSecondary。

好事多磨，我决定在 Todis 中使用 Secondary Instance 时，这个功能 RocksDB 已经实现很久了（2 年以上），所以就认为它是一个稳定可靠的功能，并没有事先去进行评测评估，直接就去用了。

然而，这一用，就用出问题了，起初自然而然地以为是我们自己的问题，但是怎么整都整不对，最终发现，这是 Secondary Instance 的 Bug，开源的优点就是，大家一起用，一起测，一起找 bug，一起修 bug，自己能修，就修了提 Pull Request，修不了，就提交给社区，这个 Bug 我们确实修不了，所以就提交给了社区，然后(两个多月后)社区就修复了(合并到主干是更久以后的事情了)。

使用 ToplingDB 性能组件

更快的 MemTab, 更快的 SST, 压缩的 SST 都只能支持 BytewiseComparator，更准确地讲，在这些组件中，Key 的序是确定的，Bytewise 的序，与 BytewiseComparator 确定的序相同。这又是为什么呢？因为这些组件底层的公共基类/接口是 BaseDFA，按 DFS 遍历 DFA，输出的 Key 集合是 Bytewise 序。

而在 pika 中，有两个自定义的 Comparator：ListsDataKeyComparator 和 ZSetsScoreKeyComparator

解决办法就是对 Key 进行编码，让编码后按 Bytewise 序，等效于自定义的 Comparator 确定的序，关于该问题，更详细的内容，可以参考我多年前写的文档。

使用 ToplingDB 分布式 Compact

人性化：增加监控指标，Todis 组件可视化