[[410735]]

本文轉(zhuǎn)載自微信公眾號(hào)「咖啡拿鐵」，作者咖啡拿鐵。轉(zhuǎn)載本文請(qǐng)聯(lián)系咖啡拿鐵公眾號(hào)。

背景

tidb這個(gè)技術(shù)名詞很多同學(xué)或多或少都曾經(jīng)耳聞過(guò)，但是很多同學(xué)覺得他是分布式數(shù)據(jù)庫(kù)，自己的業(yè)務(wù)是使用mysql，基本使用不上這個(gè)技術(shù)，可能不會(huì)去了解他。最近業(yè)務(wù)上有個(gè)需求使用到了tidb，于是學(xué)習(xí)了一下基本原理，會(huì)發(fā)現(xiàn)這些原理其實(shí)不僅僅局限于分布式數(shù)據(jù)庫(kù)這一塊，很多技術(shù)都是通用的，所以在這里寫一下分享一下學(xué)習(xí)tidb的一些心得。

先說(shuō)說(shuō)為什么選擇tidb吧，一般來(lái)說(shuō)在咱們的業(yè)務(wù)中都是使用的mysql,但是單機(jī)數(shù)據(jù)庫(kù)容量和并發(fā)性能都有限，對(duì)于一些大容量或者高并發(fā)的場(chǎng)景我們會(huì)選擇sharding-jdbc去做，使用sharding-jdbc的確解決了問(wèn)題但是增加了開發(fā)難度，我需要對(duì)我的每一個(gè)表都設(shè)置分表key，并且每個(gè)查詢都得帶入這個(gè)key的值，這樣就增加了查詢限制，如果不帶key的值就得所有庫(kù)表都得查詢一次才行，效率極低，所以我們又異構(gòu)了一份數(shù)據(jù)到es來(lái)滿足其他條件。怎么解決這個(gè)問(wèn)題呢?正好公司最近內(nèi)部在推tidb，我看了下tidb基本兼容mysql，存儲(chǔ)無(wú)限擴(kuò)展，開發(fā)成本比較低，性能整體也不錯(cuò)，所以決定使用了tidb。 

數(shù)據(jù)庫(kù)發(fā)展歷史

關(guān)系型單機(jī)數(shù)據(jù)庫(kù)

關(guān)系型數(shù)據(jù)庫(kù)的開始是以1970年Edgar F.Codd 提出了關(guān)系模型。在數(shù)據(jù)庫(kù)發(fā)展早期階段，出現(xiàn)了很多優(yōu)秀的商業(yè)數(shù)據(jù)庫(kù)產(chǎn)品，如Oracle/DB2。在1990年之后，出現(xiàn)了開源數(shù)據(jù)庫(kù)MySQL和PostgreSQL。這些數(shù)據(jù)庫(kù)不斷地提升單機(jī)實(shí)例性能，再加上遵循摩爾定律的硬件提升速度，往往能夠很好地支撐業(yè)務(wù)發(fā)展。

分布式數(shù)據(jù)庫(kù)

隨著摩爾定律的失效，單體數(shù)據(jù)庫(kù)的發(fā)展很難應(yīng)對(duì)更高級(jí)別的挑戰(zhàn)，所以就出現(xiàn)了分布式數(shù)據(jù)庫(kù)，分布式數(shù)據(jù)庫(kù)擁有應(yīng)對(duì)海量并發(fā)，海量存儲(chǔ)的能力所以能應(yīng)對(duì)更難的挑戰(zhàn)。

• nosql:HBase是其中的典型代表。HBase是Hadoop生態(tài)中的重要產(chǎn)品，Google BigTable的開源實(shí)現(xiàn)，當(dāng)然還有我們熟悉的redis，nosql有一些自己的特殊使用場(chǎng)景，所以有一些自己的弊端，BigTable不支持跨行事務(wù)，用java開發(fā)性能也跟不上，redis的話用內(nèi)存存儲(chǔ)，無(wú)法保證事務(wù)。并且nosql已經(jīng)是不靠關(guān)系模型了。
• sharding: 我們依然可以通過(guò)單機(jī)數(shù)據(jù)庫(kù)完成我們分布式數(shù)據(jù)庫(kù)的功能，我們通過(guò)某個(gè)組件實(shí)現(xiàn)對(duì)sql進(jìn)行分發(fā)到不同分片的功能，比如比較出名開源的有sharing-jdbc，mycat，阿里云上商業(yè)的有drds。sharing的話對(duì)于運(yùn)維來(lái)說(shuō)比較困難，如果需要擴(kuò)容需要不斷的進(jìn)行手動(dòng)遷移數(shù)據(jù)，還需要自己指定某一個(gè)分片key。
• newsql:在newsql中可以保證acid的事務(wù)，也維持了關(guān)系模型，并且還支持sql。比較出名的有g(shù)oole的F1和Spanner，阿里的OceanBase,pingCap的tidb。

學(xué)前提問(wèn)

在我們學(xué)習(xí)某個(gè)知識(shí)的時(shí)候，一般都是會(huì)帶著一些問(wèn)題去學(xué)習(xí)，有目的的學(xué)習(xí)會(huì)讓你更快的上手，對(duì)于tidb或者分布式數(shù)據(jù)庫(kù)，我在使用的時(shí)候會(huì)有這些疑問(wèn)：

如何保證無(wú)限擴(kuò)展?因?yàn)槠綍r(shí)使用的大多都是sharding-jdbc那種有個(gè)sharding-key的技術(shù)，這種其實(shí)無(wú)限擴(kuò)展是比較麻煩的，所以我最開始就對(duì)tidb如何保證無(wú)限擴(kuò)展發(fā)出了疑問(wèn)?

如何保證id唯一，分布式數(shù)據(jù)庫(kù)往往會(huì)進(jìn)行分片，在單機(jī)數(shù)據(jù)庫(kù)中的自增id就不成立，tidb是如何保證的呢?

如何保證事務(wù)?前面我們說(shuō)過(guò)newsql是需要支持acid的事務(wù)的，那么我們的tidb是如何保證的呢?

通過(guò)索引是如何查詢數(shù)據(jù)的呢?單機(jī)數(shù)據(jù)庫(kù)使用了索引加速查詢，tidb又是如何做到用索引加速查詢的呢?

tidb

架構(gòu)

再回答我們上面的那些問(wèn)題之前，先看一看tidb的整體架構(gòu)是什么? 

tidb其實(shí)是典型的計(jì)算分離的架構(gòu)，對(duì)計(jì)算分離架構(gòu)不熟悉的可以看看我之前的文章:聊聊計(jì)算與分離

TiDB Server：計(jì)算層，對(duì)外暴露協(xié)議的連接端口，負(fù)責(zé)管理客戶端的連接，主要做的就是執(zhí)行SQL解析以及優(yōu)化，生成分布式執(zhí)行計(jì)劃，由于這里是計(jì)算層是沒(méi)有狀態(tài)的，所以是可以無(wú)限擴(kuò)展。

PD Server:PD是整個(gè)集群的大腦，負(fù)責(zé)存儲(chǔ)每個(gè) TiKV 節(jié)點(diǎn)實(shí)時(shí)的數(shù)據(jù)分布情況和集群的整體拓?fù)浣Y(jié)構(gòu)，提供 TiDB Dashboard 管控界面，需要保持高可用。

TiKV: k-v存儲(chǔ)引擎，在tikv內(nèi)部，存儲(chǔ)數(shù)據(jù)的基本單位是Region。

Tiflash：這個(gè)是用于列式的存儲(chǔ)引擎

TSpark: 這是tidb對(duì)spark進(jìn)行支持，所以tidb他是一個(gè)HTAP的數(shù)據(jù)庫(kù)。

如何無(wú)限擴(kuò)展?

我們首先來(lái)到我們的第一個(gè)問(wèn)題，Tidb如何做到無(wú)限擴(kuò)展?

首先我們來(lái)看看計(jì)算層: tidb-server，我們剛才說(shuō)過(guò)在計(jì)算層中，是無(wú)狀態(tài)的，所以就可以進(jìn)行無(wú)限擴(kuò)展，如果你的場(chǎng)景并發(fā)度很高或者數(shù)據(jù)庫(kù)連接很多，可以考慮多擴(kuò)展tidb-server。

然后我們來(lái)看看存儲(chǔ)層，有一類數(shù)據(jù)云數(shù)據(jù)庫(kù)通常也會(huì)被誤認(rèn)為是分布式數(shù)據(jù)庫(kù)，也就是aws的auroradb和阿里云的polardb，這兩個(gè)數(shù)據(jù)庫(kù)也是采用的計(jì)算與存儲(chǔ)分離的架構(gòu)，在計(jì)算層也可以無(wú)限擴(kuò)展，但是在存儲(chǔ)層他們使用的是一份數(shù)據(jù)，這個(gè)也就是shared-storage架構(gòu)，這兩個(gè)數(shù)據(jù)庫(kù)依靠這大容量磁盤，來(lái)支撐更高容量的數(shù)據(jù)。

在tidb中是shared-nothing架構(gòu)，存儲(chǔ)層也是分離的： 

在每個(gè)tikv上會(huì)劃分出多個(gè)Region,這個(gè)也就是我們的基本存儲(chǔ)單位,大家見這個(gè)圖是不是發(fā)現(xiàn)這個(gè)架構(gòu)似曾相識(shí)呢?

從上面看，region就對(duì)應(yīng)這kafka下的partition，partition在kafka中的作用也是用來(lái)將topic的壓力打散到不同broker上，同樣的在tidb的region上也是一樣的,我們通過(guò)region為最小單位進(jìn)行存儲(chǔ)。

再詳細(xì)介紹region之前先說(shuō)一下存儲(chǔ)引擎為什么叫tikv呢?原因就是這個(gè)存儲(chǔ)引擎就是保存的就是一個(gè)key-value，你可以理解成java里面的hashmap，在tikv中沒(méi)有選擇自己研發(fā)如何將這個(gè)map數(shù)據(jù)去落地，而是通過(guò)一個(gè)非常優(yōu)秀的kv存儲(chǔ)引擎——rocksdb去進(jìn)行磁盤落地。RocksDB是Facebook開源的一個(gè)KV高性能單機(jī)數(shù)據(jù)庫(kù)，很多公司基于rocksdb做了很多優(yōu)秀的存儲(chǔ)產(chǎn)品，后面也會(huì)詳細(xì)的寫一篇介紹rocksdb的文章。

rocksdb是一個(gè)單機(jī)的存儲(chǔ)引擎那么我們是需要保證數(shù)據(jù)在分布式環(huán)境下是不丟失的，在kafka中有其他partition的副本會(huì)不斷的拉取leader副本，并且通過(guò)一個(gè)ISR的機(jī)制去維護(hù)。在tikv中，直接使用的raft協(xié)議去做數(shù)據(jù)復(fù)制，每個(gè)數(shù)據(jù)變更都會(huì)落地為一條 Raft 日志，通過(guò) Raft 的日志復(fù)制功能，將數(shù)據(jù)安全可靠地同步到復(fù)制組的每一個(gè)節(jié)點(diǎn)中。不過(guò)在實(shí)際寫入中，根據(jù) Raft 的協(xié)議，只需要同步復(fù)制到多數(shù)節(jié)點(diǎn)，即可安全地認(rèn)為數(shù)據(jù)寫入成功。

可以發(fā)現(xiàn)其實(shí)這里是寫的raft,通過(guò)raft接口再寫的rocksdb。

我們這里回到region，region還有一個(gè)partition不一樣的點(diǎn)在于，partition一般不會(huì)自動(dòng)去擴(kuò)容，在業(yè)務(wù)開發(fā)中他往往是一個(gè)恒定得值，而region不一樣，region的大小默認(rèn)是96MB，再實(shí)際得業(yè)務(wù)中，我們的region的個(gè)數(shù)會(huì)隨著我們數(shù)據(jù)量而變多，當(dāng)然如果我們的數(shù)據(jù)量變小，他也會(huì)自動(dòng)合并。

如何確定某個(gè)數(shù)據(jù)是在哪個(gè)region上呢?一般來(lái)說(shuō)有hash(key)和range(key)的方案，在tikv中選擇的是rangekey，因?yàn)閷?duì)于region分裂是比較方便的，每一個(gè)region其實(shí)就是一個(gè)[StartKey，EndKey) 的表示：

出現(xiàn)region的分裂的時(shí)候，只需要新增一個(gè)region，將老region的數(shù)據(jù)拿出一部分到新region， 譬如 [a, b) -> [a, ab) + [ab, b)，如果是hash來(lái)做的話，他會(huì)將所有region的數(shù)據(jù)都會(huì)重新hash，所以在tikv中選的是range(key)的方式，合并也是一樣。

所以對(duì)于tidb來(lái)說(shuō)無(wú)論是存儲(chǔ)層還是計(jì)算層，我們都可以無(wú)限擴(kuò)展。

如何保證id唯一

在mysql中我們可以對(duì)于主鍵直接設(shè)置 AUTO_INCREMENT來(lái)達(dá)到自增列的效果，mysql是怎么做到自增的呢?

在MySQL5.7及之前的版本：InnoDB引擎的自增值，自增值保存在內(nèi)存里，并沒(méi)有持久化。每次重啟后，第一次打開表的時(shí)候，都會(huì)去找自增值的最大值max(id)，然后將max(id)+步長(zhǎng)作為這個(gè)表當(dāng)前的自增值。

在MySQL8.0版本：將自增值的變更記錄在了redo log中，重啟的時(shí)候依靠redo log恢復(fù)重啟之前的值。

在單機(jī)中這些都好做，但是在分布式數(shù)據(jù)庫(kù)中，我們就沒(méi)法保證id的唯一了，我之前有寫過(guò)相關(guān)的文章：如果再有人問(wèn)你分布式ID，這篇文章丟給他。我們?cè)谑褂胹harding-jdbc的時(shí)候就是使用的文章介紹的leaf這個(gè)ID生成中間件，來(lái)完成ID生成。

在Tidb中同樣支持 AUTO_INCREMENT,實(shí)現(xiàn)的原理和leaf中的號(hào)段模式一樣，不能保證嚴(yán)格遞增，只能保證趨勢(shì)遞增，具體原理是：，對(duì)于每一個(gè)自增列，都使用一個(gè)全局可見的鍵值對(duì)用于記錄當(dāng)前已分配的最大 ID。由于分布式環(huán)境下的節(jié)點(diǎn)通信存在一定開銷，為了避免寫請(qǐng)求放大的問(wèn)題，每個(gè) TiDB 節(jié)點(diǎn)在分配 ID 時(shí)，都申請(qǐng)一段 ID 作為緩存，用完之后再去取下一段，而不是每次分配都向存儲(chǔ)節(jié)點(diǎn)申請(qǐng)。

tidb還支持 AUTO_RANDOM,可以用于解決大批量寫數(shù)據(jù)入 TiDB 時(shí)因含有整型自增主鍵列的表而產(chǎn)生的熱點(diǎn)問(wèn)題。因?yàn)閞egion是有序的如果一段時(shí)間大量有序的數(shù)據(jù)產(chǎn)生有可能會(huì)在同一個(gè)region上，所以我們可以使用AUTO_RANDOM來(lái)將我們的主鍵數(shù)據(jù)打散。

如何保證事務(wù)

這里我們先回顧一下事務(wù)的四大特性ACID，我們來(lái)想想在mysql的innodb中這個(gè)是怎么做的呢?

• A:原子性，指一個(gè)事務(wù)中的所有操作，或者全部完成，或者全部不完成，不會(huì)結(jié)束在中間某個(gè)環(huán)節(jié)，原子性在mysql中我們是依賴redolog和undolog共同完成
• C:一致性，指在事務(wù)開始之前和結(jié)束以后，數(shù)據(jù)庫(kù)的完整性沒(méi)有被破壞。一致性是依靠其他幾個(gè)特性來(lái)保證的。
• I:隔離性，指數(shù)據(jù)庫(kù)允許多個(gè)并發(fā)事務(wù)同時(shí)對(duì)其數(shù)據(jù)進(jìn)行讀寫和修改的能力。隔離性可以防止多個(gè)事務(wù)并發(fā)執(zhí)行時(shí)由于交叉執(zhí)行而導(dǎo)致數(shù)據(jù)的不一致，主要用于處理并發(fā)場(chǎng)景。mysql隔離性依靠的是鎖和mvcc，在mysql里面鎖的種類很豐富，mysql支持多種隔離性。
• D:持久性，事務(wù)處理結(jié)束后，對(duì)數(shù)據(jù)的修改就是永久的，即便系統(tǒng)故障也不會(huì)丟失，持久性是依靠redolog和mysql的刷盤機(jī)制。

在tidb中ACID是什么做到的呢?

• A:通過(guò) Primary Key 所在 Region 的原子性來(lái)保證分布式事務(wù)的原子。
• C:TiDB 在寫入數(shù)據(jù)之前，會(huì)校驗(yàn)數(shù)據(jù)的一致性，校驗(yàn)通過(guò)才會(huì)寫入內(nèi)存并返回成功。
• I:也是通過(guò)鎖和mvcc來(lái)完成隔離性，但是在tidb只支持RR(可重復(fù)讀)級(jí)別，RC隔離級(jí)別在4.0之后樂(lè)觀模式下也能支持。
• D:事務(wù)一旦提交成功，數(shù)據(jù)全部持久化存儲(chǔ)到 TiKV，并且還有多副本機(jī)制，如果發(fā)生宕機(jī)數(shù)據(jù)也不會(huì)丟失。

在mysql中的事務(wù)模型都是悲觀事務(wù)模型，而在tidb中事務(wù)模型提供了樂(lè)觀和悲觀兩種，怎么去理解悲觀和樂(lè)觀兩種模型呢：

• 悲觀模型：其實(shí)和名字一樣，只要在事務(wù)執(zhí)行的時(shí)候認(rèn)為每一條被你修改的數(shù)據(jù)都很大概率被其他事務(wù)修改(悲觀的看法)。在mysql里面，如果你在事務(wù)中你對(duì)某一行修改是會(huì)給你加上行鎖的，如果此時(shí)有其他事務(wù)想對(duì)這個(gè)數(shù)據(jù)進(jìn)行修改，那么其他事務(wù)會(huì)被阻塞等待住?？梢院?jiǎn)單理解成邊執(zhí)行邊檢測(cè)沖突。
• 樂(lè)觀模型：我們認(rèn)為我們修改的數(shù)據(jù)很大概率不會(huì)和其他事務(wù)產(chǎn)生沖突，所以不需要邊執(zhí)行邊進(jìn)行沖突檢測(cè)，而是最后提交的時(shí)候進(jìn)行沖突檢測(cè)。如果沖突比較少這樣就可以獲得較高的性能。

在tidb中是如何實(shí)現(xiàn)這兩種模式的呢?因?yàn)槲覀兪欠植际綌?shù)據(jù)庫(kù)，兩階段提交一般是分布式事務(wù)的通用解決方案，之前我寫過(guò)很多分布式事務(wù)相關(guān)的文章大家可以自行查閱一下。

樂(lè)觀模式

tidb同樣使用兩階段提交來(lái)保證分布式事務(wù)的原子性，分為 Prewrite 和 Commit 兩個(gè)階段：

• Prewrite：對(duì)事務(wù)修改的每個(gè) Key 檢測(cè)沖突并寫入 lock 防止其他事務(wù)修改。對(duì)于每個(gè)事務(wù)，TiDB 會(huì)從涉及到改動(dòng)的所有 Key 中選中一個(gè)作為當(dāng)前事務(wù)的 Primary Key，事務(wù)提交或回滾都需要先修改 Primary Key，以它的提交與否作為整個(gè)事務(wù)執(zhí)行結(jié)果的標(biāo)識(shí)。
• Commit：Prewrite 全部成功后，先同步提交 Primary Key，成功后事務(wù)提交成功，其他 Secondary Keys 會(huì)異步提交。

整個(gè)事務(wù)步驟如下：

• Step 1: 客戶端開啟事務(wù)，類似我們?cè)趍ysql里面的 begintrasaction;
• Step 2: TiDB 向 PD 獲取全局時(shí)間，可以知道這個(gè)事務(wù)的全局順序，用于后續(xù)mvcc的處理
• Step 3: 發(fā)起DML，比如update xxx; 這個(gè)時(shí)候不會(huì)有沖突檢測(cè)，只會(huì)在tidb內(nèi)存中進(jìn)行保存;
• Step 4: 提交事務(wù)，類似我們?cè)趍ysql里面的commit，這個(gè)時(shí)候tidb會(huì)在commit階段完成兩階段提交，先進(jìn)行prewrite 各種加鎖檢測(cè)之后如果沒(méi)有問(wèn)題再進(jìn)行commit。這里舉個(gè)例子:

begin; //step1 
 
insert into xx; // step3 
 
update xx; // step3 
 
update xx; // step3 
 
commit;// step4 

在上面的例子中如果是悲觀模式step3的時(shí)候就會(huì)進(jìn)行加鎖檢測(cè)了，樂(lè)觀模式下所有的工作都放在了commit中，所以會(huì)出現(xiàn)commit出現(xiàn)異常的狀態(tài)，所以我們使用樂(lè)觀模式需要更好的處理commit階段的異常行為，這和我們一般的編程不一樣。但是如果數(shù)據(jù)的競(jìng)爭(zhēng)不是太激烈的話是可以使用樂(lè)觀模式來(lái)提升性能的。

悲觀模式

悲觀模式把lock進(jìn)行了提前，每個(gè) DML 都會(huì)加悲觀鎖，鎖寫到 TiKV 里，同樣會(huì)通過(guò) raft 同步，在加悲觀鎖時(shí)檢查各種約束，如 Write Conflict、key 唯一性約束等。

悲觀事務(wù)下能保證我們的commit成功，這種模式比較符合我們的編程模式，所以tidb默認(rèn)的模式也是悲觀模式。

如何做的索引查詢

為什么我會(huì)想到這個(gè)索引查詢這個(gè)問(wèn)題呢?當(dāng)時(shí)是在看到了rocksdb是tidb的底層存儲(chǔ)介質(zhì)之后，我想到了在innodb中我們的索引是B+樹，如果tidb的索引是b+樹的話，那么rocksdb應(yīng)該怎么去構(gòu)造呢?

事實(shí)上在tidb中的索引也是使用的k-v形式去做的，我們先看看對(duì)于每一行的數(shù)據(jù)是怎么存儲(chǔ)的：

• 為了保證同一個(gè)表的數(shù)據(jù)放在一起，方便查找，TiDB 會(huì)為每個(gè)表分配一個(gè)表 ID，用 TableID 表示。表 ID 是一個(gè)整數(shù)，在整個(gè)集群內(nèi)唯一。
• TiDB 會(huì)為表中每行數(shù)據(jù)分配一個(gè)行 ID，用 RowID 表示。行 ID 也是一個(gè)整數(shù)，在表內(nèi)唯一。對(duì)于行 ID，TiDB 做了一個(gè)小優(yōu)化，如果某個(gè)表有整數(shù)型的主鍵，TiDB 會(huì)使用主鍵的值當(dāng)做這一行數(shù)據(jù)的行 ID。每行數(shù)據(jù)按照如下規(guī)則編碼成 (Key, Value) 鍵值對(duì)：

Key: tablePrefix{TableID}_recordPrefixSep{RowID} 
 
Value: [col1, col2, col3, col4] 

假定我們的tablePrefix是常量字符t,recordPrefixSep是常量字符r，我們的tableId是1,rowID在這里是我們的主鍵假定是100,如果有一個(gè)用戶表的數(shù)據(jù)，如下：

Key: t1_r100 
 
Value: [100, "zhangsan"] 

如果我們的主鍵為整數(shù)的情況下，那么上面也可以看作是我們的主鍵索引，如果我們的主鍵不為整型或者說(shuō)在唯一索引的情況下，規(guī)則編碼如下：

Key: tablePrefix{tableID}_indexPrefixSep{indexID}_indexedColumnsValue 
 
Value: RowID 

indexId是tidb為每個(gè)索引分配的ID，所以上面那個(gè)情況下一個(gè)indexedColumnsValue只能對(duì)應(yīng)一條數(shù)據(jù)滿足唯一性，如果是非唯一索引，我們可以有：

Key: tablePrefix{tableID}_indexPrefixSep{indexID}_indexedColumnsValue_rowId 
 
Value: null 

這樣一個(gè)indexedColumnsValue就可以有多行數(shù)據(jù)，所以其實(shí)我們r(jià)egion中的數(shù)據(jù)的索引并不會(huì)和region的數(shù)據(jù)再一起，而是有自己的region分片，同樣的我們查詢數(shù)據(jù)的時(shí)候需要依靠我們的tidb-server分析出來(lái)我們應(yīng)該用什么樣的索引，先根據(jù)索引數(shù)據(jù)查詢出來(lái)rowId再根據(jù)rowId查詢出來(lái)我們對(duì)應(yīng)的數(shù)據(jù)。

總結(jié)

不管是tidb還是分布式數(shù)據(jù)庫(kù)，要學(xué)習(xí)的知識(shí)還有非常的多，上面只是對(duì)tidb做了一些粗解的分析，如果大家要學(xué)習(xí)可以看看下面的一些資料：

pingcap文檔: https://docs.pingcap.com, ping cap的文檔是我見過(guò)做得算是比較頂級(jí)的文檔了，他可以說(shuō)不叫做文檔，其實(shí)是一個(gè)文章知識(shí)庫(kù)，我的文章很多圖和內(nèi)容都是借鑒而來(lái)。

極客時(shí)間《分布式數(shù)據(jù)庫(kù)》：極客時(shí)間有一個(gè)課叫分布式數(shù)據(jù)庫(kù)，不會(huì)局限于講tidb，主要講解的是分布式數(shù)據(jù)庫(kù)的各種知識(shí)，并且會(huì)列舉市場(chǎng)上的分布式數(shù)據(jù)庫(kù)做對(duì)比。 

《數(shù)據(jù)庫(kù)系統(tǒng)內(nèi)幕》：豆瓣評(píng)分8.5，這本書講解了很多數(shù)據(jù)庫(kù)理論基本知識(shí)，不論上分布式數(shù)據(jù)庫(kù)還是單機(jī)數(shù)據(jù)庫(kù)都會(huì)使用到，稍微有一點(diǎn)難懂，但是還是會(huì)有不少收獲。