摘要：是基于開源的兼容協(xié)議的強一致性的數(shù)據(jù)庫開源項目。這種架構類似于公司的第一代的系統(tǒng)，系統(tǒng)本身也是一個強一致性的高可用的分布式系統(tǒng)。由于篇幅所限，本文中關于強一致性線性一致性的很多技術細節(jié)的闡述未能詳盡，擬另行成文討論。

作者介紹：
陳東明，餓了么北京技術中心架構組負責人，負責餓了么的產(chǎn)品線架構設計以及餓了么基礎架構研發(fā)工作。曾任百度架構師，負責百度即時通訊產(chǎn)品的架構設計。具有豐富的大規(guī)模系統(tǒng)構 建和基礎架構的研發(fā)經(jīng)驗，善于復雜業(yè)務需求下的大并發(fā)、分布式系統(tǒng)設計和持續(xù)優(yōu)化。個人微信公眾號 dongming_cdm。

Tedis（https://github.com/eleme/tedis）是基于開源 TiKV 的兼容 Redis 協(xié)議的強一致性的 NoSQL 數(shù)據(jù)庫開源項目。 本文介紹一下 Tedis 開源項目的架構設計和特性，以及架構背后的一些思考（包括為何選擇 TiKV 和 Redis 協(xié)議）。

先來討論為什么基于 TiKV 構建我們自己的 NoSQL 數(shù)據(jù)庫。

首先簡述一下?TiKV[1]，TiKV 是 TiDB 的一個子項目，TiDB 是一個分布式的關系型數(shù)據(jù)庫?[2]，TiKV 是 TiDB 的存儲層。TiKV 本身是可獨立于 TiDB 的多帶帶項目。它是一個強一致、可水平擴展的、高可用的分布式 Key-Value 存儲系統(tǒng)。

選擇 TiKV 的第一個原因是 TiKV 是一個強一致的系統(tǒng)。 在我的另外一篇文章中（發(fā)表在 InfoQ, 參看?https://www.infoq.cn/article/rhzs0KI2G*Y2r9PMdeNv?），我闡述了一個觀點：NoSQL 數(shù)據(jù)庫應該具有一致性，并且通過多副本技術達到實際的高可用，也就是說 NoSQL 數(shù)據(jù)庫應該是一個“實際上的 CA” （effectively CA）系統(tǒng)。但是在這篇文章中我并沒有明確說明 NoSQL 該具有的一致性是哪種一致性。實際上，我所說的一致性其實就是一種強一致性?[3]，或者更準確的說是線性一致性?[4]。TiKV 正是具有這種線性一致性。TiKV 中的每個數(shù)據(jù)都會保存 3 個副本，在只有一個副本的節(jié)點宕機或者出現(xiàn)網(wǎng)絡分區(qū)的情況下，另外 2 個副本仍然能夠?qū)ν馓峁┓?。理論上來講，同時出現(xiàn) 2 個以上副本同時壞掉的可能性很小，也就是理論上可以達到非常高的可用性。通過 TiKV 滾動升級等運維輔助，如果在實際的生產(chǎn)中，有良好的運維，可以達到實際上非常高的可用性。也就是稱為一個“實際上的 CA”（effectively CA）系統(tǒng)。

TiKV 通過 Raft?[5]?協(xié)議實現(xiàn)了線性一致性和高可用 2 個特性。Raft 是一種分布式共識協(xié)議，通過 Raft 協(xié)議，數(shù)據(jù)可以被認為是原子的寫入到 3 個副本上。共識協(xié)議的一個特點就是要寫入大多數(shù)，才會認為寫入成功，3 個副本的大多數(shù)就是 2 個，也就是在只有一個副本宕機或者網(wǎng)絡分區(qū)的情況下，仍然可以成功寫入，并且提供讀服務。

選擇 TiKV 的第二個原因是 TiKV 的架構可擴展和生態(tài)。 在 TiDB 中 TiKV 是獨立的一層，形成了一個很好的可擴展架構，實際上可以在 TiKV 上擴展出很多不同的數(shù)據(jù)庫出來。TiDB 層本身就是這種架構上的一個擴展。這種架構類似于 Google 公司的第一代的 Spanner 系統(tǒng)?[6]，Spanner 系統(tǒng)本身也是一個強一致性的、高可用的分布式 Key-Value 系統(tǒng)。在 Spanner 的基礎之上，Google 構建了 F1 系統(tǒng)?[7]，實現(xiàn)了 SQL 協(xié)議。2017 年，Google 升級了 Spanner 到第二代?[8]，讓 Spanner 本身就具有了 SQL 能力。雖然一代 Spanner+F1 是這樣的架構，但它仍然是一種非常優(yōu)秀的架構。我們的 Tedis 項目，也是構建在這一可擴展架構上的一個項目，依托于 TiKV 提供的底層能力，向上構建了不同于 SQL 協(xié)議的 Redis 協(xié)議。我相信 TiKV 的這種可擴展架構，未來可以成為一種生態(tài)，還可以在上面“?出”其他的類型的數(shù)據(jù)庫，比如說 Mango 協(xié)議、圖協(xié)議。這些數(shù)據(jù)庫都具有與底層 TiKV 相同的線性一致性和高可用性，區(qū)別只在于對外的接口協(xié)議不同。 目前這種生態(tài)已初?端倪，Titan（https://github.com/distribute...）?這個開源項目，與我們的 Tedis 項目非常類似，他們的開源步伐先于我們，目前做的也非常不錯。我相信，我們肯定不是這個生態(tài)中的最后一個。

總之基于 TiKV，Tedis 實現(xiàn)了以下的技術特性：

1.?大數(shù)據(jù)量，可以存儲至少數(shù)十 TB 級別的數(shù)據(jù)。

2.?高性能，在滿足高 QPS 的同時，保證比較低的延時。

3.?高可靠，數(shù)據(jù)被可靠的持久化存儲，少量機器的損壞不會導致數(shù)據(jù)的丟失。

4.?高可用，作為在線服務的底層依賴存儲，要有非常完善的高可用性能力，外賣服務不同于電子商務，對實時性要求非常高，對系統(tǒng)的可用性的要求則是更高的。

5.?易運維，可以在不停服的基礎上進行數(shù)據(jù)遷移和集群擴容。

接下來，我們討論第二個問題，為什么選擇 Redis 協(xié)議。

SQL 語言與其背后的關系模型，從 1970s 發(fā)明以來，一直在應用開發(fā)領域占據(jù)這統(tǒng)治地位，雖然在 CAP 定理的推動下?[4]，在 NoSQL 運動中，出現(xiàn)很多 NoSQL 系統(tǒng)，就如我前面闡述的一樣，一致性不應該是 NoSQL 出現(xiàn)的理由，去 SQL 和關系模型才是 NoSQL 出現(xiàn)的動力。但我并不認為 NoSQL 會代替 SQL。雖然 NoSQL 出現(xiàn)的時候，原本表達的意思是 “NO SQL（沒有 SQL）”，但是我覺得另外一種對 NoSQL 的解釋更合適，也就是“Not?Only?SQL（不僅僅有 SQL）”。NoSQL 不是 SQL 的替代品，應該是 SQL 的有力補充。在 NoSQL 運動中，涌現(xiàn)出來的非常優(yōu)秀的 NoSQL 系統(tǒng)大多都有自己的獨有的接口協(xié)議，比如 Redis、MongoDB、Cassandra、圖數(shù)據(jù)庫等等。他們都有各自非常適用的使用場景，比如 MongoDB 貼近面向?qū)ο?，圖數(shù)據(jù)庫適合節(jié)點的圖關系運算。而 Redis 貼近開發(fā)者數(shù)據(jù)結構思維，相信每個開發(fā)者都是從數(shù)組、hash 表、隊列這樣的數(shù)據(jù)結構中成?起來的。

另外，Redis 本身是一個非常優(yōu)秀的產(chǎn)品，它的普及程度非常高，特別是在互聯(lián)網(wǎng)行業(yè)。在每個互聯(lián)網(wǎng)公司，Redis 都已經(jīng)成為工程師開發(fā)工具箱中，必備的工具之一。Redis 已經(jīng)是開發(fā)者除 SQL 之外，第二熟悉的產(chǎn)品了。

但是，選擇 Redis 協(xié)議，也給我?guī)硪恍嶋H的困擾，我們有些使用者最初接觸 Tedis 時，總是拿我們和 Redis 相比。但是，雖然我們采用的是 Redis 接口，但是?Tedis 本身并不對標 Redis 這個產(chǎn)品。Redis 是非常優(yōu)秀的緩存。雖然 Redis 也可以開啟持久化功能，由于 Redis 本身架構設計，開啟持久化的 Redis 仍然不能達到“實際上的 CA”（effectively CA），和 100% 的持久性（durability）。這是 Redis 和 Tedis 的一個很大的區(qū)別，Tedis 是一個數(shù)據(jù)庫，不是一個緩存。

討論完上面的 2 個架構思考，我們來看一下 Tedis 的架構設計。

在 Tedis 中，我們封裝了一個 TiKV 的 SDK，對 Redis 的協(xié)議進行了解析，并且將 Redis 協(xié)議轉(zhuǎn)成對 TiKV 的調(diào)用。

目前 Tedis 仍然有很多要完善的地方，但是我們會盡快完善如下的事項，在我們的開源日程表中:

1. Redis 命令的補全

2. 壓縮和限流等一些擴展功能

3. Cassandra 協(xié)議的支持

寫在最后

作為存儲系統(tǒng)，不應該讓使用者在一致性、可用性這些技術特性上做過多的選擇，使用者應該更多的考慮哪種接口更適合自己的應用場景，自己更熟練使用哪種接口，能用哪種接口更快的進行功能開發(fā)。

由于篇幅所限，本文中關于強一致性、線性一致性、Redis、Raft、Spanner 的很多技術細節(jié)的闡述未能詳盡，擬另行成文討論。

參考資料：

https://github.com/pingcap/tikv

https://github.com/pingcap/TiDB

Eventually Consistent - Revisited，Werner Vogels, 2008， http://www.allthingsdistribut... ually_consistent .html

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

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

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

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