TiDB 是什么？
TiDB 是一個(gè)分布式 NewSQL 數(shù)據(jù)庫。它支持水平彈性擴(kuò)展、ACID 事務(wù)、標(biāo)準(zhǔn) SQL、MySQL 語法和 MySQL 協(xié)議，具有數(shù)據(jù)強(qiáng)一致的高可用特性，是一個(gè)不僅適合 OLTP 場景還適合 OLAP 場景的混合數(shù)據(jù)庫。
TiDB怎么來的？
著名的開源分布式緩存服務(wù) codis 的作者，PingCAP聯(lián)合創(chuàng)始人& CTO ，資深 infrastructure 工程師的黃東旭，擅長分布式存儲(chǔ)系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)，開源狂熱分子的技術(shù)大神級(jí)別人物。即使在互聯(lián)網(wǎng)如此繁榮的今天，在數(shù)據(jù)庫這片邊界模糊且不確定地帶，他還在努力尋找確定性的實(shí)踐方向。
直到 2012 年底，他看到 google 發(fā)布的兩篇論文，如同棱鏡般，折射出他自己內(nèi)心微爍的光彩。這兩篇論文描述了 Google 內(nèi)部使用的一個(gè)海量關(guān)系型數(shù)據(jù)庫 F1/Spanner ，解決了關(guān)系型數(shù)據(jù)庫、彈性擴(kuò)展以及全球分布的問題，并在生產(chǎn)中大規(guī)模使用。“如果這個(gè)能實(shí)現(xiàn)，對(duì)數(shù)據(jù)存儲(chǔ)領(lǐng)域來說將是顛覆性的”，黃東旭為完美方案的出現(xiàn)而興奮， PingCAP 的 TiDB 在此基礎(chǔ)上誕生了。
TiDB架構(gòu)
??TiDB 集群主要分為三個(gè)組件：
１TiDB Server
TiDB Server 負(fù)責(zé)接收 SQL 請(qǐng)求，處理 SQL 相關(guān)的邏輯，并通過 PD 找到存儲(chǔ)計(jì)算所需數(shù)據(jù)的 TiKV 地址，與 TiKV 交互獲取數(shù)據(jù)，最終返回結(jié)果。 TiDB Server是無狀態(tài)的，其本身并不存儲(chǔ)數(shù)據(jù)，只負(fù)責(zé)計(jì)算，可以無限水平擴(kuò)展，可以通過負(fù)載均衡組件（如LVS、HAProxy 或F5）對(duì)外提供統(tǒng)一的接入地址。
２PD Server
Placement Driver (簡稱 PD) 是整個(gè)集群的管理模塊，其主要工作有三個(gè)： 一是存儲(chǔ)集群的元信息（某個(gè) Key 存儲(chǔ)在哪個(gè) TiKV 節(jié)點(diǎn)）；二是對(duì) TiKV 集群進(jìn)行調(diào)度和負(fù)載均衡（如數(shù)據(jù)的遷移、Raft group leader的遷移等）；三是分配全局唯一且遞增的事務(wù) ID。
PD 是一個(gè)集群，需要部署奇數(shù)個(gè)節(jié)點(diǎn)，一般線上推薦至少部署 3 個(gè)節(jié)點(diǎn)。
３TiKV Server
TiKV Server 負(fù)責(zé)存儲(chǔ)數(shù)據(jù)，從外部看 TiKV 是一個(gè)分布式的提供事務(wù)的 Key-Value 存儲(chǔ)引擎。存儲(chǔ)數(shù)據(jù)的基本單位是 Region，每個(gè) Region 負(fù)責(zé)存儲(chǔ)一個(gè) Key Range （從 StartKey 到EndKey 的左閉右開區(qū)間）的數(shù)據(jù)，每個(gè) TiKV 節(jié)點(diǎn)會(huì)負(fù)責(zé)多個(gè) Region 。TiKV 使用 Raft協(xié)議做復(fù)制，保持?jǐn)?shù)據(jù)的一致性和容災(zāi)。副本以 Region 為單位進(jìn)行管理，不同節(jié)點(diǎn)上的多個(gè) Region 構(gòu)成一個(gè) RaftGroup，互為副本。數(shù)據(jù)在多個(gè) TiKV 之間的負(fù)載均衡由 PD 調(diào)度，這里也是以 Region 為單位進(jìn)行調(diào)度。
以上三個(gè)分別是指計(jì)算、調(diào)度、存儲(chǔ)三個(gè)技術(shù)點(diǎn)：
這次重點(diǎn)講一下存儲(chǔ)：
TIKV采用的key-》value的數(shù)據(jù)模型，我們可以把TIKV想象為一個(gè)巨大的Map，里面的是按照Key的二進(jìn)制的順序進(jìn)行排序，也就是可以認(rèn)為里面存儲(chǔ)的都是一個(gè)個(gè)key-》value對(duì)，在這里我們需要記住的是這里的存儲(chǔ)模型與SQL中的Table無關(guān)！
RocksDb
任何持久化的存儲(chǔ)引擎，數(shù)據(jù)終究都是要存儲(chǔ)在磁盤之上的，TIKV也不例外，但是TIKV是沒有選擇直接將數(shù)據(jù)寫在磁盤之上的，而是采用了RocksDB，將數(shù)據(jù)交給OocksDB，由它將數(shù)據(jù)寫在磁盤上，他們采用這個(gè)的原因是開發(fā)單機(jī)的引擎要把各種細(xì)致化的話，還要滿足他們的各種需求，工作量較大。所以他們直接采用了Fecebook開發(fā)的RocksDB來使用，這樣的話，就是存儲(chǔ)的數(shù)據(jù)模型和數(shù)據(jù)的落地已經(jīng)選擇好。
Raft
目前已經(jīng)有一個(gè)高效可靠的本地存儲(chǔ)機(jī)制，現(xiàn)在要做的就是要求數(shù)據(jù)的分布，單機(jī)的存儲(chǔ)就算再強(qiáng)大，也會(huì)丟失數(shù)據(jù)，機(jī)器掛掉了，或者機(jī)房斷電了，再或者地震了等等情況，都會(huì)造成數(shù)據(jù)的丟失，所以他們要實(shí)現(xiàn)數(shù)據(jù)的分布，也就是分布式。單機(jī)不可能支持高可用。他們?cè)谶@里采用Raft協(xié)議，Raft是一致性協(xié)議，在這里我們簡單的講解一下Raft，采用這個(gè)協(xié)議可以達(dá)成三個(gè)目標(biāo)：
1. Leader 選舉
2. 成員變更
3. 日志復(fù)制
TIKV通過Raft來做數(shù)據(jù)復(fù)制，每個(gè)數(shù)據(jù)變更都會(huì)落地成為一條Raft日志，通過Raft的日志復(fù)制功能，將數(shù)據(jù)安全可靠地同步到group的多數(shù)節(jié)點(diǎn)中。
?
??到這里我們總結(jié)一下，通過單機(jī)的RocksDB，我們可以將數(shù)據(jù)快速地存儲(chǔ)在磁盤上；通過Raft，我們可以將數(shù)據(jù)復(fù)制到多臺(tái)機(jī)器上，以防單機(jī)失效。數(shù)據(jù)的寫入是通過Raft這一層的接口寫入，而不是直接寫RocksDB。通過實(shí)現(xiàn)Raft，我們擁有了一個(gè)分布式的KV，現(xiàn)在再也不用擔(dān)心某臺(tái)機(jī)器掛掉了。
Region
前面提到，我們將 TiKV 看做一個(gè)巨大的有序的 KV Map，那么為了實(shí)現(xiàn)存儲(chǔ)的水平擴(kuò)展，我們需要將數(shù)據(jù)分散在多臺(tái)機(jī)器上。這里提到的數(shù)據(jù)分散在多臺(tái)機(jī)器上和 Raft 的數(shù)據(jù)復(fù)制不是一個(gè)概念，在這一節(jié)我們先忘記 Raft，假設(shè)所有的數(shù)據(jù)都只有一個(gè)副本，這樣更容易理解。
對(duì)于一個(gè) KV 系統(tǒng)，將數(shù)據(jù)分散在多臺(tái)機(jī)器上有兩種比較典型的方案：一種是按照 Key 做 Hash，根據(jù) Hash 值選擇對(duì)應(yīng)的存儲(chǔ)節(jié)點(diǎn)；另一種是分 Range，某一段連續(xù)的 Key 都保存在一個(gè)存儲(chǔ)節(jié)點(diǎn)上。TiKV 選擇了第二種方式，將整個(gè) Key-Value 空間分成很多段，每一段是一系列連續(xù)的 Key，我們將每一段叫做一個(gè) Region，并且我們會(huì)盡量保持每個(gè) Region 中保存的數(shù)據(jù)不超過一定的大小(這個(gè)大小可以配置，目前默認(rèn)是 64MB)。每一個(gè) Region 都可以用 StartKey 到 EndKey 這樣一個(gè)左閉右開區(qū)間來描述。
?
??注意，這里的 Region 還是和 SQL 中的表沒什么關(guān)系！ 請(qǐng)各位繼續(xù)忘記 SQL，只談 KV。
將數(shù)據(jù)劃分成 Region 后，我們將會(huì)做兩件重要的事情：
- 以 Region 為單位，將數(shù)據(jù)分散在集群中所有的節(jié)點(diǎn)上，并且盡量保證每個(gè)節(jié)點(diǎn)上服務(wù)的 Region 數(shù)量差不多
- 以 Region 為單位做 Raft 的復(fù)制和成員管理
這兩點(diǎn)非常重要，我們一點(diǎn)一點(diǎn)來說。
先看第一點(diǎn)，數(shù)據(jù)按照 Key 切分成很多 Region，每個(gè) Region 的數(shù)據(jù)只會(huì)保存在一個(gè)節(jié)點(diǎn)上面。我們的系統(tǒng)會(huì)有一個(gè)組件來負(fù)責(zé)將 Region 盡可能均勻的散布在集群中所有的節(jié)點(diǎn)上，這樣一方面實(shí)現(xiàn)了存儲(chǔ)容量的水平擴(kuò)展（增加新的節(jié)點(diǎn)后，會(huì)自動(dòng)將其他節(jié)點(diǎn)上的 Region 調(diào)度過來），另一方面也實(shí)現(xiàn)了負(fù)載均衡（不會(huì)出現(xiàn)某個(gè)節(jié)點(diǎn)有很多數(shù)據(jù)，其他節(jié)點(diǎn)上沒什么數(shù)據(jù)的情況）。同時(shí)為了保證上層客戶端能夠訪問所需要的數(shù)據(jù)，我們的系統(tǒng)中也會(huì)有一個(gè)組件記錄 Region 在節(jié)點(diǎn)上面的分布情況，也就是通過任意一個(gè) Key 就能查詢到這個(gè) Key 在哪個(gè) Region 中，以及這個(gè) Region 目前在哪個(gè)節(jié)點(diǎn)上。至于是哪個(gè)組件負(fù)責(zé)這兩項(xiàng)工作，會(huì)在后續(xù)介紹。
對(duì)于第二點(diǎn)，TiKV 是以 Region 為單位做數(shù)據(jù)的復(fù)制，也就是一個(gè) Region 的數(shù)據(jù)會(huì)保存多個(gè)副本，我們將每一個(gè)副本叫做一個(gè) Replica。Repica 之間是通過 Raft 來保持?jǐn)?shù)據(jù)的一致（終于提到了 Raft），一個(gè) Region 的多個(gè) Replica 會(huì)保存在不同的節(jié)點(diǎn)上，構(gòu)成一個(gè) Raft Group。其中一個(gè) Replica 會(huì)作為這個(gè) Group 的 Leader，其他的 Replica 作為 Follower。所有的讀和寫都是通過 Leader 進(jìn)行，再由 Leader 復(fù)制給 Follower。
大家理解了 Region 之后，應(yīng)該可以理解下面這張圖：
?
??我們以 Region 為單位做數(shù)據(jù)的分散和復(fù)制，就有了一個(gè)分布式的具備一定容災(zāi)能力的 KeyValue 系統(tǒng)，不用再擔(dān)心數(shù)據(jù)存不下，或者是磁盤故障丟失數(shù)據(jù)的問題。這已經(jīng)很 Cool，但是還不夠完美，我們需要更多的功能。
MVCC
很多數(shù)據(jù)庫都會(huì)實(shí)現(xiàn)多版本控制（MVCC），TiKV 也不例外。設(shè)想這樣的場景，兩個(gè) Client 同時(shí)去修改一個(gè) Key 的 Value，如果沒有 MVCC，就需要對(duì)數(shù)據(jù)上鎖，在分布式場景下，可能會(huì)帶來性能以及死鎖問題。
TiKV 的 MVCC 實(shí)現(xiàn)是通過在 Key 后面添加 Version 來實(shí)現(xiàn)，簡單來說，沒有 MVCC 之前，可以把 TiKV 看做這樣的：
Key1 -> Value
Key2 -> Value
……
KeyN -> Value
有了 MVCC 之后，TiKV 的 Key 排列是這樣的：
Key1-Version3 -> Value
Key1-Version2 -> Value
Key1-Version1 -> Value
……
Key2-Version4 -> Value
Key2-Version3 -> Value
Key2-Version2 -> Value
Key2-Version1 -> Value
……
KeyN-Version2 -> Value
KeyN-Version1 -> Value
……
注意，對(duì)于同一個(gè) Key 的多個(gè)版本，我們把版本號(hào)較大的放在前面，版本號(hào)小的放在后面（回憶一下 Key-Value 一節(jié)我們介紹過的 Key 是有序的排列），這樣當(dāng)用戶通過一個(gè) Key + Version 來獲取 Value 的時(shí)候，可以將 Key 和 Version 構(gòu)造出 MVCC 的 Key，也就是 Key-Version。然后可以直接 Seek(Key-Version)，定位到第一個(gè)大于等于這個(gè) Key-Version 的位置。
事務(wù)
TiKV 的事務(wù)采用的是 Percolator 【
https://research.google.com/pubs/pub36726.html】模型，并且做了大量的優(yōu)化。事務(wù)的細(xì)節(jié)這里不詳述，大家可以參考論文以及我們的其他文章（點(diǎn)擊閱讀原文可查看）。這里只提一點(diǎn)，TiKV 的事務(wù)采用樂觀鎖，事務(wù)的執(zhí)行過程中，不會(huì)檢測寫沖突，只有在提交過程中，才會(huì)做沖突檢測，沖突的雙方中比較早完成提交的會(huì)寫入成功，另一方會(huì)嘗試重新執(zhí)行整個(gè)事務(wù)。當(dāng)業(yè)務(wù)的寫入沖突不嚴(yán)重的情況下，這種模型性能會(huì)很好，比如隨機(jī)更新表中某一行的數(shù)據(jù)，并且表很大。但是如果業(yè)務(wù)的寫入沖突嚴(yán)重，性能就會(huì)很差，舉一個(gè)極端的例子，就是計(jì)數(shù)器，多個(gè)客戶端同時(shí)修改少量行，導(dǎo)致沖突嚴(yán)重的，造成大量的無效重試。
