作者 | 沈劍

在做業務架構的過程中，你是否遇到過類似的痛點？

（1）數據量太大，容量復雜性上移到業務層；

（2）并發量太大，性能復雜性上移到業務層；

（3）前臺與后臺存儲異構，滿足不同查詢需求；

（4）線上與線下存儲異構，滿足大數據需求；

（5）存儲系統遷移成本高，不敢輕易做重構；

（6）...

職業生涯十五年，基本都在使用MySQL做線上業務的存儲。最近這幾年，遇到的問題慢慢多起來，嚴重影響了研發效率。TiDB近年甚火，于是最近做了一些調研，與大家分享。

如一貫風格，更多的聊：TiDB究竟解決什么問題，以及為什么這么設計，體現什么架構思想。

問題的引出，MySQL體系結構存在什么問題？

上面這幅MySQL體系結構圖，相信很多人都見過：

• 上游：MySQL客戶端；
• 下游：MySQL服務端，又包含連接池，語法分析，語義分析，查詢優化，緩沖池，存儲引擎，物理存儲，管理功能… 等諸多模塊；

畫外音：太復雜了，字都看不清了。

對MySQL體系結構做了一個簡化：

如上圖所示：

• 上游：MySQL客戶端；
• 中間：通過MySQL協議通訊；
• 下游：MySQL服務端；

畫外音：對不起，忍一下我畫的丑圖。

核心的服務端，又主要分為兩層：

• 一層，計算層；
• 一層，存儲層；

MySQL如此這般，存在什么天然的問題？

【1】計算與存儲天然耦合。

計算層和存儲層，既然都在一個MySQL進程里，所有的CPU資源，內存資源都是共享的，勢必存在資源爭搶的耦合。

除了天生的不足，在數據量大，并發量大的典型互聯網業務場景里，對于MySQL的使用，還有哪些痛點呢？

我們都知道，當讀寫量增加的時候，通常會對MySQL做主從分組集群：

如上圖所示：主從同步，讀寫分離，通過線性增加從庫來線性擴展系統的讀性能。

畫外音：大部分業務，讀容易成為主要矛盾。

我們也知道，當存儲容量增加的時候，通常會對MySQL做水平切分集群：

如上圖所示：用一個鍵值進行數據分片，以實現更大的存儲容量。

所以，實際上線上的MySQL集群是這樣的：

• 既有水平切分，多個分片；
• 又有主從分組，每個分片有一個主從集群；

而分片和分組，都是調用方微服務需要關注的，這就引出了下一個痛點：

【2】調用方需要關注存儲細節，底層存儲的復雜性轉移到了上層應用。

另外，除了在線應用，絕大部分互聯網公司都有各類大數據處理的需求：

• 離線分析：例如，經營日報；
• 在線分析：例如，分析師取數；
• 實時處理：例如，實時報表；

為了滿足這類需求，又需要將MySQL中的數據同步到各類大數據體系的集群中：

用一系列大數據的技術體系，去解決各類大數據處理的需求。

這就引出了另一個痛點：

【3】技術側需要關注數據同步，數據一致性，大數據集群的復雜性。

當然，很多技術管理者也會調研各類替代產品，以解決上述1-3的問題，例如NoSQL的代表之一MongoDB，無奈【4】升級遷移需要大量的系統改造，綜合評估之后，往往不得不放棄遷移方案，繼續忍受MySQL帶來的各種問題。

歷史的痛點，往往是創新的機會。

TiDB，它來了！

TiDB是如何設計，以解決：

(1) 計算與存儲耦合；

(2) 存儲底層的復雜性轉移；

(3) 大數據體系復雜性轉移；

(4) 系統遷移成本高；

等問題的呢？

首先，TiDB在誕生之初，就確定了：

• 復用MySQL協議；
• 計算與存儲分離；

的設計大方向。

如上圖所示：

• 上游：不需要做任何改動，可以使用MySQL的各類driver，訪問TiDB；
• 中間：通過MySQL協議通訊；
• 下游：將計算層與存儲層拆分到兩個進程里，解除資源爭搶的耦合，而這兩層的通訊則使用內部協議，對調用方透明；

如此一來，難題 (1) 和 (4) 就得到了解決。

如何解決讀寫量擴展，存儲量擴展等“底層復雜性轉移”等問題呢？

對于計算層，實現連接池，語法分析，語義分析，查詢優化等模塊，做到無狀態，并通過集群的方式擴展，這就是TiDB體系結構中的“計算引擎tidb-server”集群。對于調用方，接入層TiDB集群就是入口，其背后的復雜性對上游不可見。上圖中，簡記為【接入層（計算層）】。

畫外音：微服務架構中，站點應用和微服務層也必須無狀態化，以實現輕易的集群擴展，也是一個道理。

對于存儲層，實現一致性算法，分布式事務，MVCC并發控制，算子下推等模塊，實現原子KV存儲，也能通過集群的方式自動擴展，這就是TiDB體系結構中的“存儲引擎TiKV-server” 集群。上圖中，簡記為【存儲層】。

畫外音：這與GFS中的chunk-server很像，有了它，不再需要手動水平切分擴容了。

除此之外，需要一個擁有全局視野，實現元數據存儲，ID分配（key-id，事務ID），時間戳生成，心跳檢測，集群信息收集等模塊的master，這就是TiDB體系結構中的“PD-server”集群。上圖中，簡記為【管理層】。

畫外音：這與GFS中的master-server很像。

如此一來，難題 (2) 存儲底層讀寫容量與存儲容量的復雜性轉移問題，也得到了解決。

大數據體系的復雜性，TiDB也將其屏蔽在了內部：

• 擴展接入層，讓大數據有獨立的接入，如上圖中的TiSpark；
• 擴展存儲層，匹配以適合大數據的存儲，如上圖中的TiFlash；

畫外音：TiKV和TiFlash分別獨立存儲，且進行異步數據同步，彼此解耦。

• 擴展管理層，同時管理大數據的部分；

如此一來，難題 (3) 大數據數據同步，數據一致性，大數據集群的復雜性的問題，也得到了解決。

TiDB的架構，無處不體現著這樣的設計原則：使用者簡單易用，復雜麻煩的地方，都屏蔽到TiDB的內部。

回到開篇，如果你也正經歷著類似的痛點？

• 數據量太大，容量復雜性上移到業務層；
• 并發量太大，性能復雜性上移到業務層；
• 前臺與后臺存儲異構；
• 線上與線下存儲異構；
• 存儲系統遷移成本高；
• ...

不妨，試一試TiDB。

最后一個問題，業務架構如何快速遷移至TiDB呢？

從MySQL到TiDB的遷移過程也非常平滑：

(1) 第一步，保持服務讀寫原有MySQL集群；

(2) 第二步，將原有MySQL集群中的數據，同步到TiDB；

畫外音：TiDB的工具集很全，本文沒有擴展介紹。

(3) 第三步，服務流量切換至TiDB；

畫外音：由于保持MySQL協議，業務代碼幾乎不用修改，這是TiDB能夠成功很重要的一個原因。

今天聊了聊TiDB體系結構的宏觀設計原則，希望大家有收獲。如果對TiDB的內核感興趣，未來可以和大家聊聊它的實現細節。

畫外音：大家感興趣嗎？

源碼：https://github.com/pingcap/tidb