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

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

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

首先簡述一下TiKV[1]，TiKV 是 TiDB 的一個(gè)子項(xiàng)目，TiDB 是一個(gè)分布式的關(guān)系型數(shù)據(jù)庫[2]，TiKV 是 TiDB 的存儲(chǔ)層。TiKV 本身是可獨(dú)立于 TiDB 的單獨(dú)項(xiàng)目。它是一個(gè)強(qiáng)一致、可水平擴(kuò)展的、高可用的分布式 Key-Value 存儲(chǔ)系統(tǒng)。

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

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

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

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

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

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

3.高可靠，數(shù)據(jù)被可靠的持久化存儲(chǔ)，少量機(jī)器的損壞不會(huì)導(dǎo)致數(shù)據(jù)的丟失。

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

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

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

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

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

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

討論完上面的 2 個(gè)架構(gòu)思考，我們來看一下 Tedis 的架構(gòu)設(shè)計(jì)。

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

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

1. Redis 命令的補(bǔ)全

2. 壓縮和限流等一些擴(kuò)展功能

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

寫在最后

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

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

參考資料：

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

總結(jié)

以上是生活随笔為你收集整理的mysql创建数据库的步骤_sql创建数据库代码(关系型数据库管理系统)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。