TiDB 架构的演进和开发哲学

本文来自 CSDN《程序员》2017 年 2 月的封面报道。
对于一个从零开始的数据库来说：选择什么语言，整体架构怎么做，要不要开源，如何去测试…太多的问题需要去考量。

在本篇文章中，PingCAP 联合创始人兼 CTO 黄东旭对 TiDB 的开发历程进行了详细简介，为大家还原 TiDB 的架构演进全过程。

在大约两年前，我有一次做 MySQL 分库分表和中间件的经历，那时在中间件里做 sharding，把 16 个节点的 MySQL 扩到 32 节点，差不多要提前一个月做演练，再用一个礼拜来上线。我就在想，能不能有一个数据库可以让我们不再想分库分表这些东西？当时我们也刚刚做完 Codis，觉得分布式是个比较合适的解决方案。另外我一直在关注学术圈关于分布式数据库的最新进展，有看到谷歌在 2013 年发的 Spanner 和 F1 的论文，所以决定干脆就重新开始写一个数据库，从根本上解决 MySQL 扩展性的问题。

而决定之后发现面对的问题非常复杂：选择什么语言，整个架构怎么做，到底要不要开源……做基础软件有一个很重要的事情：写出来并不难，难的是你怎么保证这个东西写对了。尤其是对于业务方，他们所有的业务正确性是构建在基础软件的正确性上。所以，对于分布式系统来说，什么是写对了，怎么去测试，这都是很重要的问题。关于这些我想了很久。

一开始总是要起步的。当时就决定冷静一下，先确定一个目标：解决 MySQL 的问题。MySQL 是单机型数据库，它没有办法做全扩展，我们选择 MySQL 兼容，首先选择在协议和语法层面的兼容，因为已有的社区里边很多的海量的测试。第二点是用户的迁移成本，能让用户迁移得很顺畅。第三是因为万事开头难，必须得有一个明确的目标，选定一个目标去做，对开发人员来说心理的压力最小。确定目标以后，我们 3 个人的创始团队从原来的公司出来，拿了一笔比较大的风险投资，开始正式做这件事情。

兼容 MySQL 最简单的方案，就是直接用 MySQL。为了让这个东西尽快地做起来，我们一开始做了一个最简单的版本，复用 MySQL前端 代码，做一个分布式的存储引擎就可以了，这个事情想想还是蛮简单的，所以非常乐观，觉得这个战略很完美。

上图是我在 2015 年 4 月份用六个礼拜完成的第一个版本的框架，但是后来没好意思开源出来，虽然能跑，但是在性能上完全无法接受。我就想这个东西为什么这么慢？一步一步去看每一层，就想动手改，但是发现工程量巨大，比如 MySQL 的 SQL 优化器， 事务模型等等，完全没有办法下手。就像这个架构图里看到的，因为在 MySQL Engine 这一层，我们能做的事情太少了，所以就没有办法。

第一版实验到此宣告失败，现在看起来写 SQL parser 和优化器等这些已经是绕不开了，我们索性决定从头开始写，唯一给我安慰的就是终于可以使用我们最爱的编程语言了，就是 Go。

我们跟其他做这种软件的工程师的思路相反，选择了从上往下写，先写最顶层的 SQL 的接口 SQL Layer，我要保证这个东西长得跟 MySQL 一模一样，包括网络协议和语法层。从 TiDB 网络协议、SQL 的语法解析器、到 SQL 的优化器、执行器等基本从上到下写了一遍。这个阶段持续了大概三个月左右。从这个阶段开始，我们慢慢摸索出了几个实践中深有体会的开发哲学。

第一，所有计算机科学里面的问题都可以把它不停地抽象，抽象到另外一个层次上去解决。

我们完成了架构 0.2，此时 TiDB 只有一个 SQL 解析器，完全不能存数据，因为底下的存储引擎根本没有实现。我想要保证这个数据库是对的，要先保证 SQL Layer 是对的，让它可以完整的跑 MySQL 的 test。至于底下的存储我可以实现个假的或者内存里先存着，先保证我的 SQL 正常运转起来就可以了。

其实在苦哈哈的写 TiDB 的 SQL Parser 的时候我们还做了很多事情，不管是 MySQL 的 unittests，SQL logic tests，ORM tests 等，把它的测试全都收集下来，到现在大概有一千万个集成测试用例。我们还做了一个事情，就是把存储引擎这个概念抽象成很薄的几个接口，使得它去接入一个 KV engine。绝大多数的 KV engine 非常多，比如 LevelDB，RocksDB，接口的语义都是非常明确的。

几个月过去了，团队也大约有了十几个人，因为在每一层我都非常严格地要求我们团队用接口来划分，使得每一个层次上的工作都是可以并行，这对于整个项目的推进是非常有利的事情。

大概去年九月份，历史上第一个不能用来存数据的数据库——没有存储引擎的第一版 TiDB 开源了，放在 HackerNews 非常受欢迎，还被推荐到了首页。

第二，Talk is cheap，show me the tests。

做基础软件 test 是比 code 更重要的事情。比如你提了一个 Feature，我到底是合并还是不合，不能直接判断，需要看到你的 test。我们现在在 GitHub 上运营 TiDB，一个新的提交如果让整个项目的代码测试的覆盖率下降了，我是不允许你的代码合并到主干分支的，非常严格。构建一个数据库最难的并不是把它写出来，而是证明它是对的，尤其是分布式系统的测试要比单机的测试要更加困难。因为在分布式系统里面每一个节点都可能 crash，每一个网络的延迟可能是飘忽不定的，各种各样的异常情况都会发生。我们在做整个数据库的时候，第一步是完成 SQL Layer，第二步是把每个 IO，每个集群的节点交互行为全都抽象成为一个接口，使得我们可以回放整个包括 TCP/IP 包的接收顺序。一旦发现 bug，就把它重放到单元测试里面重现。不管是新的开发者或者新的模块加入，是无法相信“人”的，只相信机器。我只相信 strong test 才能不断的保证项目在可以控制的范围之内。

后来做了一个架构 0.5，因为已经有了 SQL 层，SQL 层跟存储层基本上做了完全分离，终于可以像最初的 0.1 那样，我可以接一个分布式引擎上去，当时我们接了 HBase。 HBase 是阶段性的战略选型，因为我们想既然我的 SQL Layer 写的足够稳定，那么我们先接一个分布式的引擎上去，但是我又不能在架构中引入太多不确定的变量，于是就挑选了一个在市面上能找到的，我认为最稳定的分布式引擎，先接上去看整个系统到底能不能跑起来。结果还可以，能够跑起来，但是我们的要求会更高，所以之后我们就把 HBase 扔掉了。接 HBase 这个事情标志着我们上层 SQL Layer 跟我们接口的抽象已经足够稳定，我们的 test 已经足够健壮，能让我们往下一步步去做分布式的东西。

这个架构大概是这样：

上层是 MySQL 业务层 Client，你可以用任意的 MySQL 的客户端去连接它，如果数据量大的话，你不需要再去分库分表，就把它当成无穷大的 MySQL 用就好，这个用户体验很好。因为 TiDB 是一个无状态的设计，它并不存储数据，所以你可以部署无数多个 TiDB 负载均衡。底层一开始是个 HBase，那时候是 11 月，至此距离创业半年过去了。

因为有海量的 Test 保证，让整个设计的过程没有太过困难。不过这里涉及一个问题：我们在做技术选型的时候，如果在有很大自由度的前提下，怎么去控制发挥欲望和膨胀的野心？你的敌人并不是预算，而是复杂度。你怎么控制每一层的复杂度是非常重要的，特别是对于一个架构师来说，所有的工作都是在去规避复杂度，提升开发效率和稳定性。

当时我们选择了一个非常小众的编程语言就是 Rust。首先它是一个 high performance 的编程语言，它没有 GC ，也没有 runtime，很多的创新是做在了编译器这一层，最大的特点就是安全、安全和安全，我认为它是更现代的 C++，不过 C++ 最大的问题是如果用不熟容易把自己的手脚砍断。当时我选 Rust 以后，很多朋友问我你为什么去选择它。说实话最开始我是很怕的，因为这个语言毕竟是一个新的比较小众的语言，community 也没那么大，但这是当时对于我们团队的状况来说是最优选择。我们就用 Rust 写起来，结果一不小心 TiKV 成为了 Rust 社区最大的开源项目之一。因为我们在 Rust 很早期的时候就开始用了，Rust 官方也一直在找我们来分享 Rust 的使用经验，我们也很热心的去拥抱 Rust community。 Rust 社区每周的 weekly 里面有一个固定的专栏叫做 “This week in TiKV” ，就是为我们打造的 :)

2015 年的冬天我们是在纠结中度过的。一是用最新的编程语言 Rust， 大家之前都没有接触过；第二就是，我们想要的“弹性扩展、真正的高可用、高性能、强一致”这四点要求，每一个都非常困难。

怎么办？只能去拥抱社区，不要自己去做所有的事情，一是人数有限，第二是复用是个很好的习惯，既然别人都已经干过这些事情，就不要再去重复性的工作。我们要做一个真正高可用的数据库，把高可用的分布式存储找了一圈发现 Etcd，Etcd 背后算法叫 Raft这是个一致性算法等价于 Paxos。这个算法目前来说最稳定地实现就是 Etcd 里的 Raft。而且 Etcd 是真正在生产环境中被大量认证过的 Raft 的实现。我仔细看过 Etcd 的源码，每个状态的切换都抽象成接口，我们测试是可以脱离整个网络、脱离整个 IO、脱离整个硬件的环境去构建的。我觉得这个思路非常赞，这也是为什么 CoreOS 的 Etcd 包括像 k8s 背后的元信息存储也用的是它，质量非常高，性能非常好。但是 Etcd 有一个问题是它是 GO 写的，我们已经决定去用 Rust 开发底层存储的数据库。如果用类似 paxos 这种算法，我不相信除了 Google Chubby 以外的公司有能力把它写对。但是 Raft 不一样，虽然它也很难，但是毕竟它是可以实现的东西，所以我们为了它的质量，加速我们开发的进度，我们做了一件比较疯狂的事情，就是我们把 Etcd 的 Raft 状态机的每一行代码，line by line 的翻译成了 Rust。而我们第一个转的就是所有 Etcd 本身的测试用例。我们写一模一样的 test ，保证这个东西我们 port 的过程是没有问题的。

TiDB 底层的存储引擎一开始是不能存数据的，那现在是时候要选一个真正的 Storage engine，我们觉得这个事情是一个巨坑。本地存储引擎让一个小团队去写的话基本不现实，我们就从最底层选择了 RocksDB。RocksDB 大家可以认为是一个单机的 key-value engine，前身其实是 LevelDB，是 Google 在 2011 年左右开源的 key-value 的存储引擎。 RocksDB 的背后结构是 LSM Tree，是一个对写非常友好、同时在你的机器内存比较大的时候它的读性能会非常好的数据结构 。存储引擎还有一个很重要的工作就是，需要根据你机器的性能去做针对性的调优，大家会看到像 MySQL 调优都快变成黑魔法一样的东西，RocksDB 也是一个调优能写本书的存在。大家可以看到，新一代的分布式数据库存储引擎大家都会选择 RocksDB，我觉得这是大势所趋。

从 15 年的冬天开始，我们苦逼哈哈的写了 5 个月的代码，用 Rust 去写，到 2016 年 4 月 1 日 TiKV 终于开源了。

从上图能看到，最底层是 RocksDB ，上面的分布式这一层是用 Raft，这两层虽然是我们写的，但是质量上是我们社区的盟友帮我们保证的。在 Raft 之上是 MVCC ，从这里往上，就都是我们自己来写的了。所以 TiKV 终于是一个可以实现弹性扩展、支持 ACID 事务、全局一致性，跨数据中心高可用的存储引擎了，而且性能还非常的棒。因为我没有在底下去接一个像 HDFS 的文件系统。

其实从开源到现在，我们一直在做 TiKV 的性能调优、稳定性等很多的工作，但是从架构上来看，这个架构我觉得至少在未来的五年之内，不会再有很大的变化。我一直在强调的点就是：复杂性才是你最大的敌人，我宁可是以不变应万变的姿势去应对未来突变的需求。还好，数据库这个东西的需求变化也没太多。

第三，Where there’s a metric there’s a way。

再说说 Metrices。对架构师而言一个很重要的工作就是查看系统中有哪些 block 的点，挨个解决掉这些问题。我们发现在数据库领域，有很多很多点如果能予以解决的话，性能会上去十倍。我有一个观点，所有的东西，只要有 Metrices，能被监控，这个东西就能被解决。 也就是：“Where there’s a metric there’s a way”。 一旦能重复观察性能的平衡点，性能问题是最好解决的问题，但是写对是最难的问题。

一般来说大家都在公司内部自己去审 Metrics，还有监控工具。对于我们小团队来说，或者说是一个拥抱社区的团队来说，这基本上是一个得不偿失的事情。因为你费好多劲去写一个，还不如社区里面写得好，这很麻烦。所以，我们在数据库里面内嵌了 Prometheus 和 Grafana。Prometheus 现在在硅谷太火了，它其实是一个分布式的时序数据库，但是它很适用于日志搜集和性能调优，它做得更完美的地方是它提供 DSL 去用于查询提供监控的报警，包括你可以写报警的规则。它没有一个好看的 Dashboard，这时社区里面另外一个哥们就出来，说我要去给你做一个很好看的界面，这个项目就是 Grafana。Grafana 是一个可视化的 dashboard ，它能让每一次 dashboard 排布的位置、类型、样式、大小、宽度都是可以自定义的。而且整个 Metrics 收集 Prometheus 提供了两种模式，一种是 push 的模式，一种是 pull 的模式。 对于收集监控的代码性能影响很小。

最后想补充的问题，第一就是工具。对于一个互联网出身的团队来说，其实工具是我们非常重视的一个点，可以最小化业务的迁移成本。我觉得很多在大公司做重构，或者做基础软件的工程师，最好的方式就是润物细无声。你完全不知道我在做底层的重构就莫名地重构完了，这是最完美的状态。比如我之前做 Codis，我的要求是如果用户现在在用 Twemproxy ，他迁到新的方案上必须要一行代码都没有改，你甚至完全不知道我在做迁移，这才是最好的，我认为这应该是所有做基础设施团队的自我修养。

第二就是不要意外。比如说，你在做一个数据库，你号称跟 MySQL一模一样，那么你展现出来任何跟 MySQL 不一样的东西都会让用户吓一跳，而且这是很重要的一个开发原则。

第三就是悲观预设。永远都会有各种各样的恶心事情和异常的状况发生，其实这是作为分布式系统开发工程师每天都要对自己说的话。业务的数据是重于泰山的，但是任何的基础设施都是会挂的，你的网线可能会断，整个数据中心可能会 shut down……你要预设你的数据库是一定会丢数据的，这个时候你的数据库设计才会更好。如何保护自己如何保护业务，我们做了一些神奇的工具，比如像 syncer，这个东西就是把 TiDB cluster 作为一个 假的 slave 接到 MySQL 上，业务在上面跑 MySQL ，后面存起来其实是个集群。另外还做了一个比较变态的事情，就是反向。我们顶在业务上面，下面可以接到 MySQL。MySQL 可以做 TiDB 的 slave，TiDB 可以做 MySQL 的 slave。这个功能对于业务来说是非常惊喜的。有的客户一开始想用 TiDB但是有点害怕，我说没关系，你在后面接个从，然后你在从上面去查询。比如你原来一个 SQL 跑了 20 分钟，现在我能让你跑到 10 秒以内；或者你跑了大概半年都一点数据没丢，系统非常稳定，再切成主的业务代码中更改。

一个架构师总是要去想一些未来十年会发生什么。有一个名词 Cloud-Native，我是认为一切的东西在未来都会跑在云端，如何针对云上这个环境去设计基础软件？数据库设计一个很重要的原则是，数据一旦发生了宕机它能够自动修复和均衡数据，人在里边给这些集群加机器就行了，整个集群一定要能够有自己的思考。未来怎么针对 Cloud 做基础架构，这是一个需要去思考的问题。