十年再出发：回顾我与 TiDB 的成长之旅

唐刘

从 TiDB 开发的第一天起，我们就确立了测试驱动的策略。 原因也很简单，毕竟我们做的是数据库，客户的数据可不是闹着玩的，出一次大问题，我们就能直接失业。

我们甚至一度要求测试覆盖率达到 100%，听起来挺疯狂，但确实帮我们抓出了大量潜在的 bug。

唐刘

除了常规的单元测试，我们还干了一些非常极端的事儿：
1.移植了 SQLite 的 sqllogic test，当时觉得这事儿有点浪费时间，现在回想起来，却无比感谢当年咬牙做了这个决定。
2.学习 Clojure 语言，硬着头皮做了Jepsen 测试，揪出了无数隐藏的事务 bug。
3.对核心算法用上了 TLA+ 形式化证明，虽然这玩意儿真不好搞，但做出来之后让人睡得更安心了。
4.引入 Chaos 工程，搞了个 Chaos 测试工具，最后甚至做出了一个非常受欢迎的开源项目 Chaos Mesh。

唐刘

计算层搞定后，我们接下来面临的挑战是存储层。当时我们坚决不选 C++，因为这玩意儿复杂到无法控制，招多少人可能都 hold 不住，直接放弃。

恰巧这个时候 Rust 刚发布 1.0 版本，于是我们咬咬牙选择了 Rust：
1.Rust 性能好，内存安全性高，几乎能做到代码编译过了就能稳定运行，这个特性简直神奇。
2.Rust 社区很热闹，TiKV 因此也吸引了一大批社区贡献者。

不过Rust的问题也很明显：
1.编译速度慢得要命，严重拖累开发速度；
2.早期生态几乎为零，什么轮子都得自己造，费了不少劲。

唐刘

在提到 TiKV 的时候，不得不提犯的一个巨大的错误，就是起了个让人误解的名字 —— Region。

Region 本是 HBase 里面的数据分片概念，结果碰巧云计算厂商也用 Region 表示地理区域。结果现在跟客户聊 Region，经常鸡同鸭讲，痛苦无比。

这给我们敲了个警钟：命名，真不是拍脑袋的事儿。随便起个名字，将来可能要花巨大的代价去填坑。

现在想想，如果我们早清楚的看到云的趋势，我们也不会取这么一个傻的名字了。

唐刘

虽然我们很多架构设计借鉴了 Spanner，但当年我们的客户基础设施跟 Google 的环境差太远了。Google 有TrueTime、Colossus 存储系统，而我们客户都是传统 IDC、物理机或虚拟机环境。

所以我们不得不做出妥协，设计了 Shared-Nothing 架构。

在当时，这个架构特别合适。但随着云时代的到来，这个架构逐渐显现瓶颈，未来 TiDB 也必须逐渐摆脱这些旧包袱。

唐刘

回头再看，TiDB 最初的那段时光，真的是程序员最幸福的时代：
1.天天专注于技术，单纯而快乐；
2.不断挑战新的技术问题，收获巨大的满足感；
3.用纯粹的技术热情，吸引了大量志同道合的黑客们加入我们团队。

这一切，也为我们后来的发展埋下了坚实的基础。

唐刘

三：商业化，我们怎么活下去？
灵魂拷问：“客户在哪儿？”TiDB 一开始的开发阶段，大家沉浸在技术驱动的幸福里，大家很难坐下来一起认真思考一个灵魂问题：

“我们到底靠什么赚钱？”

对于当时的我们来说，写出牛逼的代码最重要，至于赚钱，好像没那么紧迫。再加上程序员普遍都有点“理想主义”，一听到“商业化”、“赚钱”这些词，总觉得俗不可耐。

唐刘

但现实终究是现实。公司毕竟不是慈善机构，不赚钱迟早要凉。所以，越早解决“客户在哪”、“客户为什么要买”这些问题，就越能少吃点苦头。

现在回想起来，对我自己来说，真后悔没早点想清楚这些问题。毕竟，早一点考虑客户的需求，对公司发展、对自己的成长都会更有帮助。

唐刘

程序员最难的转型是什么？ 答案可能就是从“技术导向”到“客户导向”。

我们早期吃过最大的一个苦头，就是完全技术导向的思维，直接导致了一次惨痛的教训。

TiDB 有个参数之前默认是 false，这样性能很好，但宕机可能丢数据。我们在 2.0 版本做了个看似合理的决定：默认改成 true。

结果没想到，这个小小的配置改动，给当时一些开源用户带来了灾难性的后果 —— 升级完性能暴跌，业务直接崩了。

唐刘

事后我们才意识到： 更好的处理方式是老用户升级保持旧配置，新用户默认新配置。这么简单的一个道理，我们居然没想到，只因为脑子里一直是“技术自嗨”，根本没考虑真实的客户场景。

类似的错误后面也出现过几次，每一次都像在提醒我们：

“做产品要以客户场景为中心，而不是自以为是的技术逻辑。”