TiDB架構特性

TiDB 整體架構

    TiDB 叢集主要包括三個核心元件：TiDB Server，PD Server 和 TiKV Server。此外，還有用于解決使用者複雜 OLAP 需求的 TiSpark 元件和簡化雲上部署管理的 TiDB Operator 元件。

簡單得了解一下：

TiDB Server

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

PD Server

    Placement Driver (簡稱 PD) 是整個叢集的管理子產品，其主要工作有三個：

1. 存儲叢集的元資訊（某個 Key 存儲在哪個 TiKV 節點）
2. 對 TiKV 叢集進行排程和負載均衡（如資料的遷移、Raft group leader 的遷移等）
3. 配置設定全局唯一且遞增的事務 ID

PD 通過 Raft 協定 保證資料的安全性。Raft 的 leader server 負責處理所有操作，其餘的 PD server 僅用于保證高可用。建議部署奇數個 PD 節點。

TiKV Server

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

TiSpark

    TiSpark 作為 TiDB 中解決使用者複雜 OLAP 需求的主要元件，将 Spark SQL 直接運作在 TiDB 存儲層上，同時融合 TiKV 分布式叢集的優勢，并融入大資料社群生态。至此，TiDB 可以通過一套系統，同時支援 OLTP 與 OLAP，免除使用者資料同步的煩惱。

TiDB Operator

    TiDB Operator 提供在主流雲基礎設施（Kubernetes）上部署管理 TiDB 叢集的能力。它結合雲原生社群的容器編排最佳實踐與 TiDB 的專業運維知識，內建一鍵部署、多叢集混部、自動運維、故障自愈等能力，極大地降低了使用者使用和管理 TiDB 的門檻與成本。

TiDB 核心特性

TiDB 具備如下衆多特性，其中兩大核心特性為：水準擴充與高可用

高度相容 MySQL

大多數情況下，無需修改代碼即可從 MySQL 輕松遷移至 TiDB，分庫分表後的 MySQL 叢集亦可通過 TiDB 工具進行實時遷移。

對于使用者使用的時候，可以透明地從MySQL切換到TiDB 中，隻是“新MySQL”的後端是存儲“無限的”，不再受制于Local的磁盤容量。在運維使用時也可以将TiDB當做一個從庫挂到MySQL主從架構中。

分布式事務

TiDB 100% 支援标準的 ACID 事務。

一站式 HTAP 解決方案

TiDB 作為典型的 OLTP 行存資料庫，同時兼具強大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP 解決方案，一份存儲同時處理 OLTP & OLAP，無需傳統繁瑣的 ETL 過程。

雲原生 SQL 資料庫

TiDB 是為雲而設計的資料庫，支援公有雲、私有雲和混合雲，配合 TiDB Operator 項目 可實作自動化運維，使部署、配置和維護變得十分簡單。

水準彈性擴充

通過簡單地增加新節點即可實作 TiDB 的水準擴充，按需擴充吞吐或存儲，輕松應對高并發、海量資料場景。

真正金融級高可用

相比于傳統主從 (M-S) 複制方案，基于 Raft 的多數派選舉協定可以提供金融級的 100% 資料強一緻性保證，且在不丢失大多數副本的前提下，可以實作故障的自動恢複 (auto-failover)，無需人工介入。

水準擴充

無限水準擴充是 TiDB 的一大特點，這裡說的水準擴充包括兩方面：計算能力(TiDB)和存儲能力(TiKV)。

TiDB Server 負責處理 SQL 請求，随着業務的增長，可以簡單的添加 TiDB Server 節點，提高整體的處理能力，提供更高的吞吐。

TiKV 負責存儲資料，随着資料量的增長，可以部署更多的 TiKV Server 節點解決資料 Scale 的問題。

PD 會在 TiKV 節點之間以 Region 為機關做排程，将部分資料遷移到新加的節點上。

是以在業務的早期，可以隻部署少量的服務執行個體（推薦至少部署 3 個 TiKV， 3 個 PD，2 個 TiDB），随着業務量的增長，按照需求添加 TiKV 或者 TiDB 執行個體。

高可用

    高可用是 TiDB 的另一大特點，TiDB/TiKV/PD 這三個元件都能容忍部分執行個體失效，不影響整個叢集的可用性。下面分别說明這三個元件的可用性、單個執行個體失效後的後果以及如何恢複。

1. TiDB

    TiDB 是無狀态的，推薦至少部署兩個執行個體，前端通過負載均衡元件對外提供服務。當單個執行個體失效時，會影響正在這個執行個體上進行的 Session，從應用的角度看，會出現單次請求失敗的情況，重新連接配接後即可繼續獲得服務。單個執行個體失效後，可以重新開機這個執行個體或者部署一個新的執行個體。

     2. PD

    PD 是一個叢集，通過 Raft 協定保持資料的一緻性，單個執行個體失效時，如果這個執行個體不是 Raft 的 leader，那麼服務完全不受影響；如果這個執行個體是 Raft 的 leader，會重新選出新的 Raft leader，自動恢複服務。PD 在選舉的過程中無法對外提供服務，這個時間大約是3秒鐘。推薦至少部署三個 PD 執行個體，單個執行個體失效後，重新開機這個執行個體或者添加新的執行個體。

     3. TiKV

    TiKV 是一個叢集，通過 Raft 協定保持資料的一緻性（副本數量可配置，預設儲存三副本），并通過 PD 做負載均衡排程。單個節點失效時，會影響這個節點上存儲的所有 Region。對于 Region 中的 Leader 節點，會中斷服務，等待重新選舉；對于 Region 中的 Follower 節點，不會影響服務。當某個 TiKV 節點失效，并且在一段時間内（預設 30 分鐘）無法恢複，PD 會将其上的資料遷移到其他的 TiKV 節點上。

TiDB 存儲和計算能力

存儲能力-TiKV-LSM

TiKV Server通常是3+的，TiDB每份資料預設為3副本，這一點與HDFS有些相似，但是通過Raft協定進行資料複制，TiKV Server上的資料的是以Region為機關進行，由PD Server叢集進行統一排程，類似HBASE的Region排程。

TiKV叢集存儲的資料格式是KV的，在TiDB中，并不是将資料直接存儲在 HDD/SSD中，而是通過RocksDB實作了TB級别的本地化存儲方案，着重提的一點是：RocksDB和HBASE一樣，都是通過 LSM樹作為存儲方案，避免了B+樹葉子節點膨脹帶來的大量随機讀寫。從何提升了整體的吞吐量。

計算能力-TiDB Server

TiDB Server本身是無狀态的，意味着當計算能力成為瓶頸的時候，可以直接擴容機器，對使用者是透明的。理論上TiDB Server的數量并沒有上限限制。