隨著網際網路的發展，業務越來越龐大，客戶群體也越來越多，所要儲存的資料也越來越多，慢慢的就出現了分庫分表的中介軟體。

比如cobar，TDDL，atlas，sharding-jdbc，mycat等，都是非常優秀的產品，解決了各種問題，但是引入了中介軟體肯定就會增加各方面的維護成本等

這篇帶大家瞭解一款替代分庫分表的解決方案：分散式資料庫：TIDB

前言

如今硬體的價效比越來越高，網路傳輸速度越來越快，資料庫分層的趨勢逐漸顯現，人們已經不再強求用一個解決方案來解決所有的儲存問題，而是透過分層，讓快取與資料庫負責各自擅長的業務場景。

當前資料庫領域面臨各種問題，如在縮放、一致性、大資料分析、與雲基礎架構整合等方面均存在諸多問題，現有的資料庫解決方案和大資料分析引擎解決方案基本處於割裂的狀態，由於 Oracle、MySQL 資料庫並不是面向分散式環境而設計，因此即使勉強透過分庫、分表或中介軟體的方式，在資料庫層面做了分片，從本質上看也只是複製了相同的堆疊，而非針對分散式系統進行儲存和計算最佳化，這正是進行跨業務查詢或跨物理機查詢和寫入十分繁瑣的本質原因。NoSQL 雖然解決了資料庫彈性擴充套件的難題，但是卻放棄了資料的強一致性以及對 ACID 事務的支援，帶來了新的問題。

為了解決這一問題，TiDB 在架構上將計算和儲存層進行高度的抽象和分離，對混合負載的場景透過 IO 優先順序佇列，智慧副本排程，行列混合儲存等技術使其變為可能。

大家可能都沒有聽過TIDB這款分散式資料庫，但是它已經出現很久了，隨著不斷完善，也受到越來越多的企業喜愛，接下來讓我們開始瞭解TIDB吧！TIDB簡介TIDB是什麼？

TiDB 是一個分散式 NewSQL 資料庫。它支援水平彈性擴充套件、ACID 事務、標準 SQL、MySQL 語法和 MySQL 協議，具有資料強一致的高可用特性，是一個不僅適合 OLTP 場景還適合OLAP 場景的混合資料庫。

TIDB怎麼來的？

開源分散式快取服務 Codis 的作者，PingCAP 聯合創始人& CTO ，資深 infrastructure 工程師的黃東旭，擅長分散式儲存系統的設計與實現，開源狂熱分子的技術大神級別人物。即使在網際網路如此繁榮的今天，在資料庫這片邊界模糊且不確定地帶，他還在努力尋找確定性的實踐方向。

2012 年底，他看到 Google 釋出的兩篇論文，得到了很大的觸動，這兩篇論文描述了 Google 內部使用的一個海量關係型資料庫 F1/Spanner ，解決了關係型資料庫、彈性擴充套件以及全球分佈的問題，並在生產中大規模使用。“如果這個能實現，對資料儲存領域來說將是顛覆性的”，黃東旭為完美方案的出現而興奮， PingCAP 的 TiDB 在此基礎上誕生了。

TIDB的架構

TiDB在整體架構基本是參考 Google Spanner 和 F1 的設計，上分兩層為 TiDB 和 TiKV 。TiDB 對應的是 Google F1， 是一層無狀態的 SQL Layer ，相容絕大多數 MySQL 語法，對外暴露 MySQL 網路協議，負責解析使用者的 SQL 語句，生成分散式的 Query Plan，翻譯成底層 Key Value 操作傳送給 TiKV， TiKV 是真正的儲存資料的地方，對應的是 Google Spanner ，是一個分散式 Key Value 資料庫，支援彈性水平擴充套件，自動的災難恢復和故障轉移（高可用），以及 ACID 跨行事務。值得一提的是 TiKV 並不像 HBase 或者 BigTable 那樣依賴底層的分散式檔案系統，在效能和靈活性上能更好，這個對於線上業務來說是非常重要。

所以一套這樣的架構是由這樣的3類角色共同組建而成。每個部分的解釋如下：

1.TiDB Server

TiDB Server 負責接收 SQL 請求，處理 SQL 相關的邏輯，並透過 PD 找到儲存計算所需資料的 TiKV 地址，與 TiKV 互動獲取資料，最終返回結果。TiDB Server 是無狀態的，其本身並不儲存資料，只負責計算，可以無限水平擴充套件，可以透過負載均衡元件（如LVS、HAProxy 或 F5）對外提供統一的接入地址。

2.PD Server

Placement Driver (簡稱 PD) 是整個叢集的管理模組，其主要工作有三個：一是儲存叢集的元資訊（某個 Key 儲存在哪個 TiKV 節點）；二是對 TiKV 叢集進行排程和負載均衡（如資料的遷移、Raft group leader 的遷移等）；三是分配全域性唯一且遞增的事務 ID。PD 是一個叢集，需要部署奇數個節點，一般線上推薦至少部署 3 個節點。

3.TiKV Server

TiKV Server 負責儲存資料，從外部看 TiKV 是一個分散式的提供事務的 Key-Value 儲存引擎。儲存資料的基本單位是 Region，每個 Region 負責儲存一個 Key Range （從 StartKey 到 EndKey 的左閉右開區間）的資料，每個 TiKV 節點會負責多個 Region 。TiKV 使用 Raft 協議做複製，保持資料的一致性和容災。副本以 Region 為單位進行管理，不同節點上的多個 Region 構成一個 Raft Group，互為副本。資料在多個 TiKV 之間的負載均衡由 PD 排程，這裡也是以 Region 為單位進行排程。

TIDB五大核心特性一鍵水平擴縮容

得益於 TiDB 儲存計算分離的架構的設計，可按需對計算、儲存分別進行線上擴容或者縮容，擴容或者縮容過程中對應用運維人員透明。

金融級高可用

資料採用多副本儲存，資料副本透過 Multi-Raft 協議同步事務日誌，多數派寫入成功事務才能提交，確保資料強一致性且少數副本發生故障時不影響資料的可用性。可按需配置副本地理位置、副本數量等策略滿足不同容災級別的要求。

實時HTAP

提供行儲存引擎 TiKV、列儲存引擎 TiFlash 兩款儲存引擎，TiFlash 透過 Multi-Raft Learner 協議實時從 TiKV 複製資料，確保行儲存引擎 TiKV 和列儲存引擎 TiFlash 之間的資料強一致。TiKV、TiFlash 可按需部署在不同的機器，解決 HTAP 資源隔離的問題。

雲原生的分散式資料庫

專為雲而設計的分散式資料庫，透過 TiDB Operator 可在公有云、私有云、混合雲中實現部署工具化、自動化。

相容MYSQL5.7

專為雲而設計的分散式資料庫，透過 TiDB Operator 可在公有云、私有云、混合雲中實現部署工具化、自動化。

TIDB四大核心應用場景HTAP 給開發者提供了一個實時資料分析方面的新思路，不需要再去維護另一個離線的資料倉庫，既減輕了 ETL 的工作，又能節省很大一部分建立資料倉庫所用到的儲存和計算成本，HTAP 將是未來的重要趨勢。黃東旭介紹了 TiDB 的四個主要應用場景，一是 MySQL 分片與合併；二是直接替換 MySQL；三是用做資料倉庫；四是作為其他系統的一個模組。MySQL分片與合併

Syncer：

TiDB 應用的第一類場景是 MySQL 的分片與合併。對於已經在用 MySQL 的業務，分庫、分表、分片、中介軟體是常用手段，隨著分片的增多，跨分片查詢是一大難題。TiDB 在業務層相容 MySQL 的訪問協議，PingCAP 做了一個數據同步的工具——Syncer，它可以把 TiDB 作為一個 MySQL Slave，將 TiDB作為現有資料庫的從庫接在主 MySQL 庫的後方，在這一層將資料打通，可以直接進行復雜的跨庫、跨表、跨業務的實時 SQL 查詢。黃東旭提到，過去的資料庫都是一主多從，有了 TiDB 以後，可以反過來做到多主一從。

替換MySQL

第二類場景是用 TiDB 直接去替換 MySQL。如果你的IT架構在搭建之初並未考慮分庫分表的問題，全部用了 MySQL，隨著業務的快速增長，海量高併發的 OLTP 場景越來越多，如何解決架構上的弊端呢?

在一個 TiDB 的資料庫上，所有業務場景不需要做分庫分表，所有的分散式工作都由資料庫層完成。TiDB 相容 MySQL 協議，所以可以直接替換 MySQL，而且基本做到了開箱即用，完全不用擔心傳統分庫分表方案帶來繁重的工作負擔和複雜的維護成本，友好的使用者介面讓常規的技術人員可以高效地進行維護和管理。另外，TiDB 具有 NoSQL 類似的擴容能力，在資料量和訪問流量持續增長的情況下能夠透過水平擴容提高系統的業務支撐能力，並且響應延遲穩定。

黃東旭在演講中提到了摩拜單車的案例，摩拜早期的資料庫全部用 MySQL，隨著業務的快速增長，MySQL 的弊端逐漸顯現，摩拜單車於 2017 年初開始使用 TiDB 替換 MySQL。如今，摩拜的 IT 系統中已部署了數套 TiDB 叢集，近百個節點，承載著數十 TB 的各類資料。

資料倉庫

TiDB 本身是一個分散式系統，第三種使用場景是將 TiDB 當作資料倉庫使用。TPC-H 是資料分析領域的一個測試集，TiDB 2.0 在 OLAP 場景下的效能有了大幅提升，原來只能在資料倉庫裡面跑的一些複雜的 Query，在 TiDB 2.0 裡面跑，時間基本都能控制在 10 秒以內。當然，因為 OLAP 的範疇非常大，TiDB的 SQL 也有搞不定的情況，為此 PingCAP 開源了 TiSpark，TiSpark 是一個 Spark 外掛，使用者可以直接用 Spark SQL 實時地在 TiKV 上做大資料分析。

作為其他系統的模組

TiDB 是一個傳統的儲存跟計算分離的專案，其底層的 Key-Value 層，可以單獨作為一個 HBase 的 Replacement 來用，它同時支援跨行事務。TiDB 對外提供兩個 API 介面，一個是 ACID Transaction 的 API，用於支援跨行事務；另一個是 Raw API，它可以做單行的事務，換來的是整個效能的提升，但不提供跨行事務的 ACID 支援。使用者可以根據自身的需求在兩個 API 之間自行選擇。例如有一些使用者直接在 TiKV 之上實現了 Redis 協議，將 TiKV 替換一些大容量，對延遲要求不高的 Redis 場景。

與MySQL相容性對比

TiDB 支援包括跨行事務，JOIN 及子查詢在內的絕大多數 MySQL 的語法，使用者可以直接使用現有的 MySQL 客戶端連線。如果現有的業務已經基於 MySQL 開發，大多數情況不需要修改程式碼即可直接替換單機的 MySQL。

包括現有的大多數 MySQL 運維工具（如 PHPMyAdmin, Navicat, MySQL Workbench 等），以及備份恢復工具（如 mysqldump, mydumper/myloader）等都可以直接使用。

不過一些特性由於在分散式環境下沒法很好的實現，目前暫時不支援或者是表現與 MySQL 有差異。

一些 MySQL 語法在 TiDB 中可以解析透過，但是不會做任何後續的處理，例如 Create Table 語句中 Engine 以及 Partition 選項，都是解析並忽略。

不支援的特性有以下這些：

儲存過程，檢視，觸發器，自定義函式，外來鍵約束，全文索引，空間索引，非 UTF8 字符集等

總結

本文帶你瞭解了TIDB這款分散式資料庫，它的特性，應用場景以及與MySQl的相容性對比，下篇將會介紹TIDB的部署搭建，計算，儲存，排程方面的知識！

假如面試中你被問到這些，我相信你看了這篇一定能撥動面試官的心！