一、前言

大家如果看過我之前發(fā)過的文章就知道，我寫過很多篇關(guān)于 MySQL 的文章，從我的 Github 匯總倉庫 中可以看出來：

可能還不是很全，算是對 MySQL 有一個淺顯但較為全面的理解。之前跟朋友聊天也會聊到，基于現(xiàn)有的微服務(wù)架構(gòu)，絕大多數(shù)的性能瓶頸都不在服務(wù)，因為我們的服務(wù)是可以橫向擴(kuò)展的。

在很多的 case 下，這個瓶頸就是「數(shù)據(jù)庫」。例如，我們?yōu)榱藴p輕 MySQL 的負(fù)擔(dān)，會引入消息隊列來對流量進(jìn)行削峰;再例如會引入 Redis 來緩存一些不太常變的數(shù)據(jù)，來減少對 MySQL 的請求。

另一方面，如果業(yè)務(wù)往 MySQL 中灌入了海量的數(shù)據(jù)，不做優(yōu)化的話，會影響 MySQL 的性能。而對于這種情況，就需要進(jìn)行分庫分表，落地起來還是較為麻煩的。

聊著聊著，就聊到了分布式數(shù)據(jù)庫。其對數(shù)據(jù)的存儲方式就類似于 Redis Cluster 這種，不管你給我灌多少的數(shù)據(jù)，理論上我都能夠吞下去。這樣一來也不用擔(dān)心后期數(shù)據(jù)量大了需要進(jìn)行分庫分表。

剛好，之前閑逛的時候看到了 PingCAP 的 TiDB，正好就來聊一聊。

二、正文

由于是簡單了解，所以更多的側(cè)重點在存儲

1.TiDB Server

還是從一個黑盒子講起，在沒有了解之前，我們對 TiDB 的認(rèn)識就是，我們往里面丟數(shù)據(jù)，TiDB 負(fù)責(zé)存儲數(shù)據(jù)。并且由于是分布式的，所以理論上只要存儲資源夠，多大的數(shù)據(jù)都能夠存下。

我們知道，TiDB 支持 MySQL，或者說兼容大多數(shù) MySQL 的語法。那我們就還是拿一個 Insert 語句來當(dāng)作切入點，探索數(shù)據(jù)在 TiDB 中到底是如何存儲的。

首先要執(zhí)行語句，必然要先建立連接。

在 MySQL 中，負(fù)責(zé)處理客戶端連接的是 MySQL Server，在 TiDB 中也有同樣的角色 —— TiDB Server，雖角色類似，但兩者有著很多的不同。

TiDB Server 對外暴露 MySQL 協(xié)議，負(fù)責(zé) SQL 的解析、優(yōu)化，并最終生成分布式執(zhí)行計劃，MySQL 的 Server 層也會涉及到 SQL 的解析、優(yōu)化，但與 MySQL 最大的不同在于，TiDB Server 是無狀態(tài)的。

而 MySQL Server 由于和底層存儲引擎的耦合部署在同一個節(jié)點，并且在內(nèi)存中緩存了頁的數(shù)據(jù)，是有狀態(tài)的。

這里其實可以簡單的把兩者理解為，TiDB 是無狀態(tài)的可橫向擴(kuò)展的服務(wù)。而 MySQL 則是在內(nèi)存中緩存了業(yè)務(wù)數(shù)據(jù)、無法橫向擴(kuò)展的單體服務(wù)。

而由于 TiDB Server 的無狀態(tài)特性，在生產(chǎn)中可以啟動多個實例，并通過負(fù)載均衡的策略來對外提供統(tǒng)一服務(wù)。

實際情況下，TiDB 的存儲節(jié)點是單獨、分布式部署的，這里只是為了方便理解 TiDB Server 的橫向擴(kuò)展特性，不用糾結(jié)，后面會聊到存儲

總結(jié)下來，TiDB Server 只干一件事：負(fù)責(zé)解析 SQL，將實際的數(shù)據(jù)操作轉(zhuǎn)發(fā)給存儲節(jié)點。

2.TiKV

我們知道，對于 MySQL，其存儲引擎(絕大多數(shù)情況)是 InnoDB，其存儲采用的數(shù)據(jù)結(jié)構(gòu)是 B+ 樹，最終以 .ibd 文件的形式存儲在磁盤上。那 TiDB 呢?

TiDB 的存儲是由 TiKV 來負(fù)責(zé)的，這是一個分布式、支持事務(wù)的 KV 存儲引擎。說到底，它就是個 KV 存儲引擎。

用大白話說，這就是個巨大的、有序的 Map。但說到 KV 存儲，很多人可能會聯(lián)想到 Redis，數(shù)據(jù)大多數(shù)時候是放在內(nèi)存，就算是 Redis，也會有像 RDB 和 AOF 這樣的持久化方式。那 TiKV 作為一個分布式的數(shù)據(jù)庫，也不例外。它采用 RocksDB 引擎來實現(xiàn)持久化，具體的數(shù)據(jù)落地由其全權(quán)負(fù)責(zé)。

RocksDB 是由 Facebook 開源的、用 C++ 實現(xiàn)的單機(jī) KV 存儲引擎。

3.索引數(shù)據(jù)

直接拿官網(wǎng)的例子給大家看看，話說 TiDB 中有這樣的一張表：

然后表里有三行數(shù)據(jù)：

這三行數(shù)據(jù)，每一行都會被映射成為一個鍵值對：

其中，Key 中的 t10 代表 ID 為 10 的表，r1 代表 RowID 為 1 的行，由于我們建表時制定了主鍵，所以 RowID 就為主鍵的值。Value 就是該行除了主鍵之外的其他字段的值，上圖表示的就是主鍵索引。

那如果是非聚簇索引(二級索引)呢?就比如索引 idxAge，建表語句里對 Age 這一列建立了二級索引：

i1 代表 ID 為 1 的索引，即當(dāng)前這個二級索引，10、20、30 則是索引列 Age 的值，最后的 1、2、3 則是對應(yīng)的行的主鍵 ID。從建索引的語句部分可以看出來，idxAge 是個普通的二級索引，不是唯一索引。所以索引中允許存在多個 Age 為 30 的列。

但如果我們是唯一索引呢?

只拿表 ID、索引 ID 和索引值來組成 Key，這樣一來如果再次插入 Age 為 30 的數(shù)據(jù)，TiKV 就會發(fā)現(xiàn)該 Key 已經(jīng)存在了，就能做到唯一鍵檢測。

4.存儲細(xì)節(jié)

知道了列數(shù)據(jù)是如何映射成 Map 的，我們就可以繼續(xù)了解存儲相關(guān)的細(xì)節(jié)了。

從圖中，我們可以看出個問題：如果某個 TiKV 節(jié)點掛了，那么該節(jié)點上的所有數(shù)據(jù)是不是都沒了?

當(dāng)然不是的，TiDB 可以是一款金融級高可用的分布式關(guān)系型數(shù)據(jù)庫，怎么可能會讓這種事發(fā)生。

TiKV 在存儲數(shù)據(jù)時，會將同一份數(shù)據(jù)想辦法存儲到多個 TiKV 節(jié)點上，并且使用 Raft 協(xié)議來保證同一份數(shù)據(jù)在多個 TiKV 節(jié)點上的數(shù)據(jù)一致性。

上圖為了方便理解，進(jìn)行了簡化。實際上一個 TiKV 中有存在 2 個 RocksDB。一個用于存儲 Raft Log，通常叫 RaftDB，而另一個用于存儲用戶數(shù)據(jù)，通常叫 KVDB。

簡單來說，就是會選擇其中一份數(shù)據(jù)作為 Leader 對外提供讀、寫服務(wù)，其余的作為 Follower 僅僅只同步 Leader 的數(shù)據(jù)。當(dāng) Leader 掛掉之后，可以自動的進(jìn)行故障轉(zhuǎn)移，從 Follower 中重新選舉新的 Leader 出來。

看到這，是不是覺得跟 Kafka 有那么點神似了。Kafka 中一個 Topic 是邏輯概念，實際上會分成多個 Partition，分散到多個 Broker 上，并且會選舉一個 Leader Partition 對外提供服務(wù)，當(dāng) Leader Partition 出現(xiàn)故障時，會從 Follower Partiiton 中重新再選舉一個 Leader 出來。

那么，Kafka 中選舉、提供服務(wù)的單位是 Partition，TiDB 中的是什么呢?

5.Region

答案是 Region。剛剛講過，TiKV 可以理解為一個巨大的 Map，而 Map 中某一段連續(xù)的 Key 就是一個 Region。不同的 Region 會保存在不同的 TiKV 上。

一個 Region 有多個副本，每個副本也叫 Replica，多個 Replica 組成了一個 Raft Group。按照上面介紹的邏輯，某個 Replica 會被選作 Leader，其余 Replica 作為 Follower。

并且，在數(shù)據(jù)寫入時，TiDB 會盡量保證 Region 不會超過一定的大小，目前這個值是 96M。當(dāng)然，還是可能會超過這個大小限制。

每個 Region 都可以用 [startKey, endKey) 這樣一個左閉右開的區(qū)間來表示。

但不可能讓它無限增長是吧?所以 TiDB 做了一個最大值的限制，當(dāng) Region 的大小超過144M(默認(rèn)) 后，TiKV 會將其分裂成兩個或更多個 Region，以保證數(shù)據(jù)在各個 Region 中的均勻分布;同理，當(dāng)某個 Region 由于短時間刪除了大量的數(shù)據(jù)之后，會變的比其他 Region 小很多，TiKV 會將比較小的兩個相鄰的 Region 合并。

大致的存儲機(jī)制、高可用機(jī)制上面已經(jīng)簡單介紹了。

但其實上面還遺留一了比較大的問題。大家可以結(jié)合上面的圖思考，一條查詢語句過來，TiDB Server 解析了之后，它是怎么知道自己要找的數(shù)據(jù)在哪個 Region 里?這個 Region 又在哪個 TiKV 上?

難道要遍歷所有的 TiKV 節(jié)點?用腳想想都不可能這么完。剛剛講到多副本，除了要知道提供讀、寫服務(wù)的 Leader Replica 所在的 TiKV，還需要知道其余的 Follower Replica 都分別在哪個實例等等。

6.PD

這就需要引入 PD 了，有了 PD 「存儲相關(guān)的細(xì)節(jié)」那幅圖就會變成這樣：

PD 是個啥?其全名叫 Placement Driver，用于管理整個集群的元數(shù)據(jù)，你可以把它當(dāng)成是整個集群的控制節(jié)點也行。PD 集群本身也支持高可用，至少由 3 個節(jié)點組成。舉個對等的例子應(yīng)該就好理解了，你可以把 PD 大概理解成 Zookeeper，或者 RocketMQ 里的 NameServer。Zookeeper 不必多說，NameServer 是負(fù)責(zé)管理整個 RocketMQ 集群的元數(shù)據(jù)的組件。

擔(dān)心大家杠，所以特意把大概兩個字加粗了。因為 PD 不僅僅負(fù)責(zé)元數(shù)據(jù)管理，還擔(dān)任根據(jù)數(shù)據(jù)分布狀態(tài)進(jìn)行合理調(diào)度的工作。

這個根據(jù)數(shù)據(jù)狀態(tài)進(jìn)行調(diào)度，具體是指啥呢?

7.調(diào)度

舉個例子，假設(shè)每個 Raft Group 需要始終保持 3 個副本，那么當(dāng)某個 Raft Group 的 Replica 由于網(wǎng)絡(luò)、機(jī)器實例等原因不可用了，Replica 數(shù)量下降到了 1 個，此時 PD 檢測到了就會進(jìn)行調(diào)度，選擇適當(dāng)?shù)臋C(jī)器補(bǔ)充 Replica;Replica 補(bǔ)充完后，掉線的又恢復(fù)了就會導(dǎo)致 Raft Group 數(shù)量多于預(yù)期，此時 PD 會合理的刪除掉多余的副本。

一句話概括上面描述的特性：PD 會讓任何時候集群內(nèi)的 Raft Group 副本數(shù)量保持預(yù)期值。

這個可以參考 Kubernetes 里的 Replica Set 概念，我理解是很類似的。

或者，當(dāng) TiDB 集群進(jìn)行存儲擴(kuò)容，向存儲集群新增 TiKV 節(jié)點時，PD 會將其他 TiKV 節(jié)點上的 Region 遷移到新增的節(jié)點上來。

或者，Leader Replica 掛了，PD 會從 Raft Group 的 Replica 中選舉出一個新的 Leader。

再比如，熱點 Region 的情況，并不是所有的 Region 都會被頻繁的訪問到，PD 就需要對這些熱點 Region 進(jìn)行負(fù)載均衡的調(diào)度。

總結(jié)一下 PD 的調(diào)度行為會發(fā)現(xiàn)，就 3 個操作：

• 增加一個 Replica
• 刪除一個 Replica
• 將 Leader 角色在一個 Raft Group 的不同副本之間遷移

了解完了調(diào)度的操作，我們再整體的理解一下調(diào)度的需求，這點 TiDB 的官網(wǎng)有很好的總結(jié)，我把它們整理成腦圖供大家參考：

大多數(shù)點都還好，只是可能會對「控制負(fù)載均衡的速度」有點問題。因為 TiDB 集群在進(jìn)行負(fù)載均衡時，會進(jìn)行 Region 的遷移，可以理解為跟 Redis 的 Rehash 比較耗時是類似的問題，可能會影響線上的服務(wù)。

8.心跳

PD 而要做到調(diào)度這些決策，必然需要掌控整個集群的相關(guān)數(shù)據(jù)，比如現(xiàn)在有多少個 TiKV?多少個 Raft Group?每個 Raft Group 的 Leader 在哪里等等，這些其實都是通過心跳機(jī)制來收集的。

在 NameServer 中，所有的 RocketMQ Broker 都會將自己注冊到 NameServer 中，并且定時發(fā)送心跳，Broker 中保存的相關(guān)數(shù)據(jù)也會隨心跳一起發(fā)送到 NameServer 中，以此來更新集群的元數(shù)據(jù)。

PD 和 TiKV 也是類似的操作，TiKV 中有兩個組件會和 PD 交互，分別是：

• Raft Group 的 Leader Replica
• TiKV 節(jié)點本身

PD 通過心跳來收集數(shù)據(jù)，更新維護(hù)整個集群的元數(shù)據(jù)，并且在心跳返回時，將對應(yīng)的「調(diào)度指令」返回。

值得注意的是，上圖中每個 TiKV 中 Raft 只連了一條線，實際上一個 TiKV 節(jié)點上可能會有多個 Raft Group 的 Leader

Store(即 TiKV 節(jié)點本身)心跳會帶上當(dāng)前節(jié)點存儲的相關(guān)數(shù)據(jù)，例如磁盤的使用狀況、Region 的數(shù)量等等。通過上報的數(shù)據(jù)，PD 會維護(hù)、更新 TiKV 的狀態(tài)，PD 用 5 種狀態(tài)來標(biāo)識 TiKV 的存儲，分別是：

• Up：這個懂的都懂，不懂的解釋了也不懂(手動 doge)
• Disconnect：超過 20 秒沒有心跳，就會變成該狀態(tài)
• Down：Disconnect 了 max-store-down-time 的值之后，就會變成 Down，默認(rèn) 30 分鐘。此時 PD 會在其他 Up 的 TiKV 上補(bǔ)足 Down 掉的節(jié)點上的 Region
• Offline：通過 PD Control 進(jìn)行手動下線操作，該 Store 會變?yōu)?Offline 狀態(tài)。PD 會將該節(jié)點上所有的 Region 搬遷到其他 Store 上去。當(dāng)所有的 Region 遷移完成后，就會變成 Tomstone 狀態(tài)
• Tombstone：表示已經(jīng)涼透了，可以安全的清理掉了。

其官網(wǎng)的圖已經(jīng)畫的很好了，就不再重新畫了，以下狀態(tài)機(jī)來源于 TiDB 官網(wǎng)：

Raft Leader 則更多的是上報當(dāng)前某個 Region 的狀態(tài)，比如當(dāng)前 Leader 的位置、Followers Region 的數(shù)量、掉線 Follower 的個數(shù)、讀寫速度等，這樣 TiDB Server 層在解析的時候才知道對應(yīng)的 Leader Region 的位置。