Tedis：基于 TiKV 构建的 NoSQL 数据库

做者介绍： 陈东明，饿了么北京技术中心架构组负责人，负责饿了么的产品线架构设计以及饿了么基础架构研发工做。曾任百度架构师，负责百度即时通信产品的架构设计。具备丰富的大规模系统构 建和基础架构的研发经验，善于复杂业务需求下的大并发、分布式系统设计和持续优化。我的微信公众号 dongming_cdm。

Tedis（https://github.com/eleme/tedis）是基于开源 TiKV 的兼容 Redis 协议的强一致性的 NoSQL 数据库开源项目。 本文介绍一下 Tedis 开源项目的架构设计和特性，以及架构背后的一些思考（包括为什么选择 TiKV 和 Redis 协议）。

先来讨论为何基于 TiKV 构建咱们本身的 NoSQL 数据库。

首先简述一下 TiKV[1]，TiKV 是 TiDB 的一个子项目，TiDB 是一个分布式的关系型数据库 [2]，TiKV 是 TiDB 的存储层。TiKV 自己是可独立于 TiDB 的单独项目。它是一个强一致、可水平扩展的、高可用的分布式 Key-Value 存储系统。

选择 TiKV 的第一个缘由是 TiKV 是一个强一致的系统。 在个人另一篇文章中（发表在 InfoQ, 参看 https://www.infoq.cn/article/rhzs0KI2G*Y2r9PMdeNv ），我阐述了一个观点：NoSQL 数据库应该具备一致性，而且经过多副本技术达到实际的高可用，也就是说 NoSQL 数据库应该是一个“实际上的 CA” （effectively CA）系统。可是在这篇文章中我并无明确说明 NoSQL 该具备的一致性是哪一种一致性。实际上，我所说的一致性其实就是一种强一致性 [3]，或者更准确的说是线性一致性 [4]。TiKV 正是具备这种线性一致性。TiKV 中的每一个数据都会保存 3 个副本，在只有一个副本的节点宕机或者出现网络分区的状况下，另外 2 个副本仍然可以对外提供服务。理论上来说，同时出现 2 个以上副本同时坏掉的可能性很小，也就是理论上能够达到很是高的可用性。经过 TiKV 滚动升级等运维辅助，若是在实际的生产中，有良好的运维，能够达到实际上很是高的可用性。也就是称为一个“实际上的 CA”（effectively CA）系统。

TiKV 经过 Raft [5] 协议实现了线性一致性和高可用 2 个特性。Raft 是一种分布式共识协议，经过 Raft 协议，数据能够被认为是原子的写入到 3 个副本上。共识协议的一个特色就是要写入大多数，才会认为写入成功，3 个副本的大多数就是 2 个，也就是在只有一个副本宕机或者网络分区的状况下，仍然能够成功写入，而且提供读服务。

选择 TiKV 的第二个缘由是 TiKV 的架构可扩展和生态。 在 TiDB 中 TiKV 是独立的一层，造成了一个很好的可扩展架构，实际上能够在 TiKV 上扩展出不少不一样的数据库出来。TiDB 层自己就是这种架构上的一个扩展。这种架构相似于 Google 公司的第一代的 Spanner 系统 [6]，Spanner 系统自己也是一个强一致性的、高可用的分布式 Key-Value 系统。在 Spanner 的基础之上，Google 构建了 F1 系统 [7]，实现了 SQL 协议。2017 年，Google 升级了 Spanner 到第二代 [8]，让 Spanner 自己就具备了 SQL 能力。虽然一代 Spanner+F1 是这样的架构，但它仍然是一种很是优秀的架构。咱们的 Tedis 项目，也是构建在这一可扩展架构上的一个项目，依托于 TiKV 提供的底层能力，向上构建了不一样于 SQL 协议的 Redis 协议。我相信 TiKV 的这种可扩展架构，将来能够成为一种生态，还能够在上面“⻓出”其余的类型的数据库，好比说 Mango 协议、图协议。这些数据库都具备与底层 TiKV 相同的线性一致性和高可用性，区别只在于对外的接口协议不一样。 目前这种生态已初⻅端倪，Titan（https://github.com/distributedio/titan） 这个开源项目，与咱们的 Tedis 项目很是相似，他们的开源步伐先于咱们，目前作的也很是不错。我相信，咱们确定不是这个生态中的最后一个。

总之基于 TiKV，Tedis 实现了如下的技术特性：

1. 大数据量，能够存储至少数十 TB 级别的数据。

2. 高性能，在知足高 QPS 的同时，保证比较低的延时。

3. 高可靠，数据被可靠的持久化存储，少许机器的损坏不会致使数据的丢失。

4. 高可用，做为在线服务的底层依赖存储，要有很是完善的高可用性能力，外卖服务不一样于电子商务，对实时性要求很是高，对系统的可用性的要求则是更高的。

5. 易运维，能够在不停服的基础上进行数据迁移和集群扩容。

接下来，咱们讨论第二个问题，为何选择 Redis 协议。

SQL 语言与其背后的关系模型，从 1970s 发明以来，一直在应用开发领域占据这统治地位，虽然在 CAP 定理的推进下 [4]，在 NoSQL 运动中，出现不少 NoSQL 系统，就如我前面阐述的同样，一致性不该该是 NoSQL 出现的理由，去 SQL 和关系模型才是 NoSQL 出现的动力。但我并不认为 NoSQL 会代替 SQL。虽然 NoSQL 出现的时候，本来表达的意思是 “NO SQL（没有 SQL）”，可是我以为另一种对 NoSQL 的解释更合适，也就是“Not Only SQL（不只仅有 SQL）”。NoSQL 不是 SQL 的替代品，应该是 SQL 的有力补充。在 NoSQL 运动中，涌现出来的很是优秀的 NoSQL 系统大多都有本身的独有的接口协议，好比 Redis、MongoDB、Cassandra、图数据库等等。他们都有各自很是适用的使用场景，好比 MongoDB 贴近面向对象，图数据库适合节点的图关系运算。而 Redis 贴近开发者数据结构思惟，相信每一个开发者都是从数组、hash 表、队列这样的数据结构中成⻓起来的。

另外，Redis 自己是一个很是优秀的产品，它的普及程度很是高，特别是在互联网行业。在每一个互联网公司，Redis 都已经成为工程师开发工具箱中，必备的工具之一。Redis 已是开发者除 SQL 以外，第二熟悉的产品了。

可是，选择 Redis 协议，也给我带来一些实际的困扰，咱们有些使用者最初接触 Tedis 时，老是拿咱们和 Redis 相比。可是，虽然咱们采用的是 Redis 接口，可是 Tedis 自己并不对标 Redis 这个产品。Redis 是很是优秀的缓存。虽然 Redis 也能够开启持久化功能，因为 Redis 自己架构设计，开启持久化的 Redis 仍然不能达到“实际上的 CA”（effectively CA），和 100% 的持久性（durability）。这是 Redis 和 Tedis 的一个很大的区别，Tedis 是一个数据库，不是一个缓存。

讨论完上面的 2 个架构思考，咱们来看一下 Tedis 的架构设计。

在 Tedis 中，咱们封装了一个 TiKV 的 SDK，对 Redis 的协议进行了解析，而且将 Redis 协议转成对 TiKV 的调用。

目前 Tedis 仍然有不少要完善的地方，可是咱们会尽快完善以下的事项，在咱们的开源日程表中:

1. Redis 命令的补全

2. 压缩和限流等一些扩展功能

3. Cassandra 协议的支持

写在最后

做为存储系统，不该该让使用者在一致性、可用性这些技术特性上作过多的选择，使用者应该更多的考虑哪一种接口更适合本身的应用场景，本身更熟练使用哪一种接口，能用哪一种接口更快的进行功能开发。

因为篇幅所限，本文中关于强一致性、线性一致性、Redis、Raft、Spanner 的不少技术细节的阐述未能详尽，拟另行成文讨论。

参考资料：

1. https://github.com/pingcap/tikv

2. https://github.com/pingcap/TiDB

3. Eventually Consistent - Revisited，Werner Vogels, 2008， http://www.allthingsdistributed.com/2008/12/event ually_consistent .html

4. Linearizability: A Correctness Condition for Concurrent Objects，Maurice P. Herlihy and Jeannette M. Wing，1990

5. In Search of an Understandable Consensus Algorithm, Diego Ongaro and John Ousterhout, 2014

6. Spanner: Google’s Globally-Distributed Database, James C. Corbett, Jeffrey Dean et al., 2012

7. F1: A Distributed SQL Database That Scales, Jeff Shute et al., 2013 8.Spanner: Becoming a SQL System, David F. Bacon et al., 2017