newsql新品TiDB的整體架構
TiDB 是 PingCAP 公司受 Google Spanner / F1 論文啟發而設計的開源分散式 NewSQL 資料庫。
TiDB 具備如下 NewSQL 核心特性：
SQL支援（TiDB 是 MySQL 相容的）
水平彈性擴充套件（吞吐可線性擴充套件）
分散式事務
跨資料中心資料強一致性保證
故障自恢復的高可用
海量資料高併發實時寫入與實時查詢（HTAP 混合負載）
TiDB 的設計目標是 100% 的 OLTP 場景和 80% 的 OLAP 場景，更復雜的 OLAP 分析可以通過 TiSpark 專案來完成。
TiDB 對業務沒有任何侵入性，能優雅的替換傳統的資料庫中介軟體、資料庫分庫分表等 Sharding 方案。同時它也讓開發運維人員不用關注資料庫 Scale 的細節問題，專注於業務開發，極大的提升研發的生產力。
要深入瞭解 TiDB 的水平擴充套件和高可用特點，首先需要了解 TiDB 的整體架構。TiDB 叢集主要包括三個核心元件：TiDB Server，PD Server 和 TiKV Server。此外，還有用於解決使用者複雜 OLAP 需求的 TiSpark 元件。
TiDB Architecture
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 為單位進行排程。
TiSpark
TiSpark 作為 TiDB 中解決使用者複雜 OLAP 需求的主要元件，將 Spark SQL 直接執行在 TiDB 儲存層上，同時融合 TiKV 分散式叢集的優勢，並融入大資料社群生態。至此，TiDB 可以通過一套系統，同時支援 OLTP 與 OLAP，免除使用者資料同步的煩惱。
TiDB 核心特性
本文詳細介紹 TiDB 的兩大核心特性：水平擴充套件與高可用。
水平擴充套件
無限水平擴充套件是 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 節點失效，並且在一段時間內（預設 30 分鐘）無法恢復，PD 會將其上的資料遷移到其他的 TiKV 節點上。
相關文章
- newsql新品TiDB之儲存SQLTiDB
- newsql新品TiDB之排程SQLTiDB
- TiDB整體架構介紹TiDB架構
- TiDB簡介與整體架構TiDB架構
- Docker整體架構Docker架構
- Tomcat的整體架構Tomcat架構
- Dubbo框架————整體架構框架架構
- 專案-整體架構架構
- Linux核心的整體架構Linux架構
- 淺析NewSQL資料庫——TiDBSQL資料庫TiDB
- 4.3. Oracle整體架構Oracle架構
- Flutter系列（三） 整體架構Flutter架構
- Underscore 整體架構淺析架構
- Netty整體架構解析Netty架構
- MySQL整體架構與記憶體結構MySql架構記憶體
- jQuery整體架構原始碼解析jQuery架構原始碼
- 鴻篇鉅製 —— LevelDB 的整體架構架構
- ==[圖]Spark系列(四)整體架構分析Spark架構
- jQuery原始碼分析系列 : 整體架構jQuery原始碼架構
- 瓜子智慧線上客服整體架構架構
- 一張圖進階 RocketMQ - 整體架構MQ架構
- 簡單瞭解 TiDB 架構TiDB架構
- 細緻解析：kubernets整體架構架構
- 死磕Tomcat系列(1)——整體架構Tomcat架構
- 【Mybatis原始碼解析】- 整體架構及原理MyBatis原始碼架構
- 精盡 MyBatis 原始碼分析 - 整體架構MyBatis原始碼架構
- RPC框架整體架構設計分析RPC框架架構
- 《高效能MySQL》筆記-整體架構MySql筆記架構
- OkHttp 3.7原始碼分析（一）——整體架構HTTP原始碼架構
- Oracle記憶體詳解之一 整體架構Oracle記憶體架構
- 完整社交APP需求分析原型設計整體架構前端後端架構APP原型架構前端後端
- 8張圖瞭解JAVA整體構架知識體系！Java
- Android5.0 vold-整體架構Android架構
- 大資料平臺的整體架構由哪些組成大資料架構
- Tomcat是如何執行的？整體架構又是怎樣的？Tomcat架構
- MyBatis原始碼窺探(一):MyBatis整體架構解析MyBatis原始碼架構
- IT基礎架構整體解決方案供應商架構
- SimpleRpc-系統邊界以及整體架構RPC架構