TiDB簡介與整體架構
TiDB 簡介
TiDB 是 PingCAP 公司受 Google / 論文啟發而設計的開源分散式 NewSQL 資料庫。
TiDB 具備如下 NewSQL 核心特性:
- SQL支援(TiDB 是 MySQL 相容的)
- 水平彈性擴充套件(吞吐可線性擴充套件)
- 分散式事務
- 跨資料中心資料強一致性保證
- 故障自恢復的高可用
- 海量資料高併發實時寫入與實時查詢(HTAP 混合負載)
TiDB 的設計目標是 100% 的 OLTP 場景和 80% 的 OLAP 場景,更復雜的 OLAP 分析可以透過 來完成。
TiDB 對業務沒有任何侵入性,能優雅的替換傳統的資料庫中介軟體、資料庫分庫分表等 Sharding 方案。同時它也讓開發運維人員不用關注資料庫 Scale 的細節問題,專注於業務開發,極大的提升研發的生產力。
TiDB 整體架構
要深入瞭解 TiDB 的水平擴充套件和高可用特點,首先需要了解 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 節點上。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/24930246/viewspace-2151630/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- TiDB整體架構介紹TiDB架構
- newsql新品TiDB的整體架構SQLTiDB架構
- 軟體架構簡介架構
- MySQL整體架構與記憶體結構MySql架構記憶體
- 簡單瞭解 TiDB 架構TiDB架構
- Docker整體架構Docker架構
- nginx 整體架構Nginx架構
- WebServiceCXF與Restful架構風格簡介WebREST架構
- Dubbo框架————整體架構框架架構
- 專案-整體架構架構
- ELK架構簡介架構
- 第5講回顧:FATE整體架構介紹與系統實踐架構
- 一. SpringCloud簡介與微服務架構SpringGCCloud微服務架構
- 4.3. Oracle整體架構Oracle架構
- Flutter系列(三) 整體架構Flutter架構
- Tomcat的整體架構Tomcat架構
- Underscore 整體架構淺析架構
- Netty整體架構解析Netty架構
- 微服務架構簡介微服務架構
- Flume(一):簡介架構架構
- 十大常用軟體架構模式簡介架構模式
- 淺談JVM整體架構與調優引數JVM架構
- Linux核心的整體架構Linux架構
- jQuery整體架構原始碼解析jQuery架構原始碼
- postgresql相關開源軟體及架構簡介SQL架構
- DM 原始碼閱讀系列文章(二)整體架構介紹原始碼架構
- 四種JavaEE架構簡介Java架構
- 微服務架構模式簡介微服務架構模式
- Microservice架構模式簡介ROS架構模式
- 軟體架構與架構師架構
- SSD演算法程式碼介訓練演算法整體架構演算法架構
- 搭建JEESZ分散式架構--訊息中介軟體簡介分散式架構
- ==[圖]Spark系列(四)整體架構分析Spark架構
- jQuery原始碼分析系列 : 整體架構jQuery原始碼架構
- 瓜子智慧線上客服整體架構架構
- 一張圖進階 RocketMQ - 整體架構MQ架構
- Android 圖形架構簡介Android架構
- Redux技術架構簡介(一)Redux架構