一、前言

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

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

在很多的 case 下，這個瓶頸就是「數據庫」。例如，我們為了減輕 MySQL 的負擔，會引入消息隊列來對流量進行削峰;再例如會引入 Redis 來緩存一些不太常變的數據，來減少對 MySQL 的請求。

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

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

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

二、正文

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

1.TiDB Server

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

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

首先要執行語句，必然要先建立連接。

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

TiDB Server 對外暴露 MySQL 協議，負責 SQL 的解析、優化，并最終生成分布式執行計劃，MySQL 的 Server 層也會涉及到 SQL 的解析、優化，但與 MySQL 最大的不同在于，TiDB Server 是無狀態的。

而 MySQL Server 由于和底層存儲引擎的耦合部署在同一個節點，并且在內存中緩存了頁的數據，是有狀態的。

這里其實可以簡單的把兩者理解為，TiDB 是無狀態的可橫向擴展的服務。而 MySQL 則是在內存中緩存了業務數據、無法橫向擴展的單體服務。

而由于 TiDB Server 的無狀態特性，在生產中可以啟動多個實例，并通過負載均衡的策略來對外提供統一服務。

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

總結下來，TiDB Server 只干一件事：負責解析 SQL，將實際的數據操作轉發給存儲節點。

2.TiKV

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

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

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

RocksDB 是由 Facebook 開源的、用 C++ 實現的單機 KV 存儲引擎。

3.索引數據

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

然后表里有三行數據：

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

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

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

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

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

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

4.存儲細節

知道了列數據是如何映射成 Map 的，我們就可以繼續了解存儲相關的細節了。

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

當然不是的，TiDB 可以是一款金融級高可用的分布式關系型數據庫，怎么可能會讓這種事發生。

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

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

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

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

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

5.Region

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

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

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

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

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

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

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

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

6.PD

這就需要引入 PD 了，有了 PD 「存儲相關的細節」那幅圖就會變成這樣：

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

擔心大家杠，所以特意把大概兩個字加粗了。因為 PD 不僅僅負責元數據管理，還擔任根據數據分布狀態進行合理調度的工作。

這個根據數據狀態進行調度，具體是指啥呢?

7.調度

舉個例子，假設每個 Raft Group 需要始終保持 3 個副本，那么當某個 Raft Group 的 Replica 由于網絡、機器實例等原因不可用了，Replica 數量下降到了 1 個，此時 PD 檢測到了就會進行調度，選擇適當的機器補充 Replica;Replica 補充完后，掉線的又恢復了就會導致 Raft Group 數量多于預期，此時 PD 會合理的刪除掉多余的副本。

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

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

或者，當 TiDB 集群進行存儲擴容，向存儲集群新增 TiKV 節點時，PD 會將其他 TiKV 節點上的 Region 遷移到新增的節點上來。

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

再比如，熱點 Region 的情況，并不是所有的 Region 都會被頻繁的訪問到，PD 就需要對這些熱點 Region 進行負載均衡的調度。

總結一下 PD 的調度行為會發現，就 3 個操作：

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

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

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

8.心跳

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

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

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

• Raft Group 的 Leader Replica
• TiKV 節點本身

PD 通過心跳來收集數據，更新維護整個集群的元數據，并且在心跳返回時，將對應的「調度指令」返回。

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

Store(即 TiKV 節點本身)心跳會帶上當前節點存儲的相關數據，例如磁盤的使用狀況、Region 的數量等等。通過上報的數據，PD 會維護、更新 TiKV 的狀態，PD 用 5 種狀態來標識 TiKV 的存儲，分別是：

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

其官網的圖已經畫的很好了，就不再重新畫了，以下狀態機來源于 TiDB 官網：

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