TiDB架構
TiDB簡介：
TiDB 是 PingCAP 公司基于 Google Spanner / F1 論文實作的開源分布式 NewSQL 資料庫。
TiDB 具備如下 NewSQL 核心特性：
- SQL支援 （TiDB 是 MySQL 相容的）
- 水準線性彈性擴充
- 分布式事務
- 跨資料中心資料強一緻性保證
- 故障自恢複的高可用
TiDB 的設計目标是 100% 的 OLTP 場景和 80% 的 OLAP 場景。
TiDB系統的架構：
TiDB 叢集主要分為三個元件：
TiDB Server
TiDB Server 負責接收 SQL 請求，處理 SQL 相關的邏輯，并通過 PD 找到存儲計算所需資料的 TiKV 位址，與 TiKV 互動擷取資料，最終傳回結果。 TiDB Server 是無狀态的，其本身并不存儲資料，隻負責計算，可以無限水準擴充，可以通過負載均衡元件（如LVS、HAProxy 或 F5）對外提供統一的接入位址。
PD Server
Placement Driver (簡稱 PD) 是整個叢集的管理子產品，其主要工作有三個： 一是存儲叢集的元資訊（某個 Key 存儲在哪個 TiKV 節點）；二是對 TiKV 叢集進行排程和負載均衡（如資料的遷移、Raft group leader 的遷移等）；三是配置設定全局唯一且遞增的事務 ID。
PD 是一個叢集，需要部署奇數個節點，一般線上推薦至少部署 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 Server 負責處理 SQL 請求，随着業務的增長，可以簡單的添加 TiDB Server 節點，提高整體的處理能力，提供更高的吞吐。TiKV 負責存儲資料，随着資料量的增長，可以部署更多的 TiKV Server 節點解決資料 Scale 的問題。PD 會在 TiKV 節點之間以 Region 為機關做排程，将部分資料遷移到新加的節點上。是以在業務的早期，可以隻部署少量的服務執行個體（推薦至少部署 3 個 TiKV， 3 個 PD，2 個 TiDB），随着業務量的增長，按照需求添加 TiKV 或者 TiDB 執行個體。
高可用
高可用是 TiDB 的另一大特點，TiDB/TiKV/PD 這三個元件都能容忍部分執行個體失效，不影響整個叢集的可用性。下面分别說明這三個元件的可用性、單個執行個體失效後的後果以及如何恢複。
-
TiDB
TiDB 是無狀态的，推薦至少部署兩個執行個體，前端通過負載均衡元件對外提供服務。當單個執行個體失效時，會影響正在這個執行個體上進行的 Session，從應用的角度看，會出現單次請求失敗的情況，重新連接配接後即可繼續獲得服務。單個執行個體失效後，可以重新開機這個執行個體或者部署一個新的執行個體。
-
PD
PD 是一個叢集，通過 Raft 協定保持資料的一緻性，單個執行個體失效時，如果這個執行個體不是 Raft 的 leader，那麼服務完全不受影響；如果這個執行個體是 Raft 的 leader，會重新選出新的 Raft leader，自動恢複服務。PD 在選舉的過程中無法對外提供服務，這個時間大約是3秒鐘。推薦至少部署三個 PD 執行個體，單個執行個體失效後，重新開機這個執行個體或者添加新的執行個體。
-
TiKV
TiKV 是一個叢集，通過 Raft 協定保持資料的一緻性（副本數量可配置，預設儲存三副本），并通過 PD 做負載均衡排程。單個節點失效時，會影響這個節點上存儲的所有 Region。對于 Region 中的 Leader 結點，會中斷服務，等待重新選舉；對于 Region 中的 Follower 節點，不會影響服務。當某個 TiKV 節點失效，并且在一段時間内（預設 10 分鐘）無法恢複，PD 會将其上的資料遷移到其他的 TiKV 節點上。
其中SQL 層架構：