TiDB架構特性

1.1. TiDB 整體架構

TiDB 集群主要包括三個核心組件：TiDB Server，PD Server 和 TiKV Server。此外，還有用於解決用戶復雜 OLAP 需求的 TiSpark 組件和簡化雲上部署管理的 TiDB Operator 組件。

架構圖解

1.1.1. TiDB Server

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

1.1.2. PD Server

Placement Driver (簡稱 PD) 是整個集群的管理模塊，其主要工作有三個：一是存儲集群的元信息（某個 Key 存儲在哪個 TiKV 節點）；二是對 TiKV 集群進行調度和負載均衡（如數據的遷移、Raft group leader 的遷移等）；三是分配全局唯一且遞增的事務 ID。

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

1.1.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 為單位進行調度。

1.1.4. TiSpark

TiSpark 作為 TiDB 中解決用戶復雜 OLAP 需求的主要組件，將 Spark SQL 直接運行在 TiDB 存儲層上，同時融合 TiKV 分布式集群的優勢，並融入大數據社區生態。至此，TiDB 可以通過一套系統，同時支持 OLTP 與 OLAP，免除用戶數據同步的煩惱。

1.1.5. TiDB Operator

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

1.2. TiDB 核心特性

TiDB 具備如下眾多特性,其中兩大核心特性為：水平擴展與高可用

1. 高度兼容 MySQL

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

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

2. 分布式事務

TiDB 100% 支持標准的 ACID 事務。

3. 一站式 HTAP 解決方案

HTAP: Hybrid Transactional/Analytical Processing

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

4. 雲原生 SQL 數據庫

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

5. 水平彈性擴展

通過簡單地增加新節點即可實現 TiDB 的水平擴展，按需擴展吞吐或存儲，輕松應對高並發、海量數據場景。

6. 真正金融級高可用

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

1.2.1. 水平擴展

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

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

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

PD 會在 TiKV 節點之間以 Region 為單位做調度，將部分數據遷移到新加的節點上。

所以在業務的早期，可以只部署少量的服務實例（推薦至少部署 3 個 TiKV， 3 個 PD，2 個 TiDB），隨着業務量的增長，按照需求添加 TiKV 或者 TiDB 實例。

1.2.2. 高可用

高可用是 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 節點上。

1.3. TiDB 存儲和計算能力

1.3.1. 存儲能力-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+樹葉子節點膨脹帶來的大量隨機讀寫。從何提升了整體的吞吐量。

1.3.2. 計算能力-TiDB Server

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

1.4. 總結

TiDB作為新一代的NewSQL數據庫，在數據庫領域已經逐漸站穩腳跟，結合了Etcd/MySQL/HDFS/HBase/Spark等技術的突出特點，隨着TiDB的大面積推廣，會逐漸弱化 OLTP/OLAP的界限，並簡化目前冗雜的ETL流程，引起新一輪的技術浪潮。

一言以蔽之，TiDB，前景可待，未來可期。