上周写了一篇 PD 的招聘广告，想想还是应该写一下 TiKV，毕竟谁叫 TiKV 也缺人了。这里，我仍然会详细的说明 TiKV 主要是干啥的，以及我们要做的事情，这样你大概就知道我们做的东西靠不靠谱，愿不愿意参与了。
在我们官网上面，TiKV 的招聘职责就两个：
- 负责分布式数据库 TiKV 相关的设计，开发
- 负责构建分布式压力测试框架，稳定性测试框架
看起来是不是一脸懵逼，这是啥。实话，我其实也想好好的写清楚，但无奈 TiKV 这边要做的事情实在是太多，只能这里慢慢唠叨了。
TiKV 简介
TiKV 是一个支持事务的，数据强一致的分布式 Key-Value 数据库。也许有人会说，造一个 Key-Value 数据库有啥难的，我不这么认为，因为造一个工业级，通用的，有超高性能的 Key-Value 真的是一件很难的事情。而且这个 Key-Value 数据库上面还加了很多限定词来修饰，要支持这些特定就更难了。后面我会一个一个的自底向上来说明 TiKV 是如何实现这些特性的。
TiKV 采用分层架构设计，这样好处在于各个模块特性都是独立解耦合的，大家可以专注于某一层的研究和开发。但同时，这些独立的模块最终会形成 TiKV 这一个整体。所以我们内部还是会要求大家不光仅仅局限于一层，而是要能精通多个模块，所以在 TiKV，你的压力会很大，但如果你是一个典型的自我驱动力很强的人，你会在这边快速的成长。
Storage
作为一个 Key-Value 存储系统，最底层当然是考虑如何去存储 Key-Value 了。在这里，我们并没有发扬程序员的『撸起袖子自己造轮子』这种光荣的优良传统，而是直接使用 RocksDB。主要原因就在于 RocksDB 已经足够好，我们短时间造一个还真不可能比它强。与其冒风险花很长时间去弄一个自己的底层 Key-Value，还不如基于 RocksDB 来更加稳妥和保险。
但我们并不只是单纯的使用 RocksDB，如果我们这边就只是用 RocksDB 的 API，那我也不好意思在这里写下去了。在 RocksDB 这边，我们需要：
- 源码级别的精通 RocksDB，也就是我们在使用 RocksDB 的时候遇到了任何问题，我们都可以帮助 RocksDB Team 去 fix。去年我们已经帮 RocksDB Team fix 了几个严重的丢数据 bug 了。
- 调优 RocksDB，RocksDB 虽然上手简单，但里面那一堆的参数，你要把它们给折腾好，适配到不同的机型，也是一个困难的事情，这块就不光要求你对 RocksDB 非常熟悉，也需要对操作系统有很深入的了解了。
- 增强 RocksDB，我们今年会跟 RocksDB 社区一起合作，参与 BlobDB 的开发，也不排除会参与到其他一些 feature 的开发，但这些 feature 我们也会争取 merge 到 RocksDB 的主干。
当然，引擎不光只有 RocksDB，在一些特定场景，譬如 Raft log，我们会考虑使用自己的存储引擎，毕竟这些场景都比较简单，写一个定制的性能会好很多，而且难度也不大。
Raft
上面说了存储引擎，但这个只能解决单个机器数据存储的问题，作为一个分布式系统，我们必须要将数据复制到多个机器上面，保证数据的安全。这里，我们就要使用分布式一致性算法了。分布式一致性算法，现在无非就是两类，Paxos 和 Raft，我们选择了 Raft。至于 Raft 的介绍，我之前写过了很多，包括小猪佩奇系列，这里就不多说了。
也许你要说，光一个 Raft，这么简单，还要做啥。但实话，要做的东西多着了：
- PreVote 特性的支持。大家知道，在 Raft 里面，只要一个节点被隔离出去，在重新回到集群的时候，就可能讲 Leader 下线，集群就要重新选举。为了缓解这个问题，需要 PreVote，但这个特性现在我们是没有的。
- Joint consensus，安全的成员变更。当我们要进行集群扩容缩容的时候，采用的是每次变更一个节点的做法，但这个方式在一些情况下面会有 corner case 问题。所以更好的方式就是 Raft 里面提到的 Joint consensus。另一个可选的方式就是支持 Replace Node 命令，但也需要处理一些 corner case。
- Multi Raft。光一个 Raft 是不可能承载这么多数据的，所以我们一定要支持多 Raft 集群，这里就要关心 Raft Group 如何分裂成多个 Group，同时这些 Group 又如何合并成一个 Group。另外当有很多 Group 之后，对于长时间没有工作的 Group，我们如何降低它们的权重，让它们静默不占用资源。这些问题，在数据量变的特大之后，都是一个非常严峻的考验。
- Huge Raft Group。现在我们的 Raft Group 是 96 MB 的，预计我们会逐渐调大，可能会到 GB 级别。这样，对于 Raft 副本的迁移，以及在这个 Raft 对应的状态机上面的数据操作，都需要有更优化的考量了。
Transaction
TiKV 是支持分布式事务的，虽然我们有 Raft，但也只能保证一个 Raft 里面数据的一致性问题，如果外面的一个操作涉及到多个 Raft 了，那么就需要使用分布式事务来保证数据的一致性了。
通用的分布式事务实现方式就是 2 PC，TiKV 采用的是 Google Percolator 模型的。现在 TiKV 的事务还有很多事情要做：
- 稳定性。分布式事务的正确性是我们首要保证的，如果你的事务实现不能满足 ACID 特定，那么根本不能用到用户的核心系统上面。所以我们需要做非常多的测试来验证我们的事务实现是正确的。
- TSO。我在之前的文章中写过我们跟 Percolator 一样使用的是 TSO，但对于 Go 程序来说，一些 goroutine 调度等就可能造成获取 TSO 变慢，所以我们也考虑优化这块，不排除以后整合 TSO 和 HLC。
- 冲突事务的优化。Percolator 使用的是乐观事务，所以对于冲突事务其实性能并不好。对于这种情况，我们可以考虑引入悲观锁等机制来优化。
- 跟引擎的结合。如何高效的让事务跟底层引擎结合起来，让事务处理的更快，也是一个需要考虑的问题。譬如如何在 RocksDB 里面如何高效的获取特定版本的数据，或者扫描的时候如何快速的过滤掉不需要的数据，都是不小的挑战。
gRPC
TiKV 现在的网络框架采用的 gRPC，关于 gRPC，之前也说了很多支持它的血泪史，但现在我们也仅仅限于支持了，还有很多东西要做：
- 性能提升。gRPC 现在对 CPU 的要求还是比较高，为了减少 CPU 的开销，我们需要更加深入的了解 gRPC 代码，所以这里也需要源码级别的精通 gRPC，知道 HTTP/2，以及 gRPC 是如何实现的。
- 网络工具。有时候我们遇到的一些网络问题，需要快速的定位，但现在其实缺少 gRPC 相关的工具。当然，一个做法是用 tcpdump 抓包，然后在弄出来使用 Wireshark 来进行分析，但这样毕竟不高效，如果能有自己的工具来对整个 gRPC 链路进行分析处理，会更好。
- Rust gRPC ecosystem。在 Go 里面，我们可以使用 go 的 gRPC ecosystem 来方便的将 gRPC 跟其他系统，譬如 OpenTracing，Prometheus 这些整合，但 Rust 这边要做的工作还有非常多。
Coprocessor
Coprocessor 的主要是为了支持 TiDB 和 TiSpark 的下推操作，这里简单说一下要做的事情：
- 支持更多的 Push 函数，这个其实就是将 TiDB 和 TiSpark 需要支持的函数实现。虽然看起来是一个辛苦活，但这个对克服 Rust，快速参与 TiKV 开发，帮助都是非常大的。
- 资源隔离。对于不同的查询语句，TP 发上来的和 AP 发上来的我们的关注度是不一样的，同时我们也需要保证 AP 的大查询不能将整个系统资源给耗尽，影响到 TP 的操作。
- 查询的提速，譬如返回更多的 hint 给 TiDB 的优化器，用来调优后面的查询。
Performance and Test
上面说了一些重要模块需要做的工作，对于 TiKV 来说，还有两个非常重要的地方，是我们非常关注的，就是性能和测试。这两块其实算是比较通用的，会涉及到所有的模块，主要是：
- 对各个模块进行性能测试，得到各模块的性能极限，为后面的性能优化提供指导。
- 对各个模块进行详细的测试，使用 failpoint 等对系统进行注入测试。
- 实践 Chaos，对系统进行大规模长时间的稳定性测试。
- 使用 TLA+ 验证系统设计的正确性。
- 设计并实现性能回归测试平台，任何提交，我们都能非常方便的知道跟之前版本的性能对比这些的，知道这次提交到底在那些地方影响了性能。
- 使用 Jepsen 和 Porcupine 等验证系统的线性一致性。
- 操作系统的调优，包括 IO，network 等。
因为性能和测试涉及到的东西太多，这里就不一一列举了。
小结
因为之前已经在 PD 那边文章里面说到了为啥要加入我们，这里就不重复了。只是想在强调一次，在 TiKV，你的个人能力会得到极大的提升，因为你要做的事情真的是太有挑战了。
要求其实跟 PD 那边的也差不多，毕竟 TiKV 其实跟 PD 是一起的，你也可以都要去开发。但 TiKV 这边对 Rust 语言要求会更高一点，你必须要克服 Rust 这个门槛。
好了，说了这么多，相信你也对我们有所了解了，你可以先去了解下 TiKV，代码在 https://github.com/pingcap/tikv，欢迎给我们提 issue 和 PR。
如果你对我们感兴趣，欢迎联系我，直接发邮箱到 tl@pingcap.com 就可以了。
网友评论