開源分佈式 NewSQL 數據庫 TiDB 2.0

TiDB 簡介與總體架構

TiDB 簡介

TiDB 是 PingCAP 公司受 Google Spanner / F1 論文啓發而設計的開源分佈式 HTAP (Hybrid Transactional and Analytical Processing) 數據庫，結合了傳統的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，支持無限的水平擴展，具有強一致性和高可用性。TiDB 的目標是爲 OLTP (Online Transactional Processing) 和 OLAP (Online Analytical Processing) 場景提供一站式的解決方案。

TiDB 具有以下核心特性：

• 高度兼容 MySQL

  大多數狀況下，無需修改代碼便可從 MySQL 輕鬆遷移至 TiDB，分庫分表後的 MySQL 集羣亦可經過 TiDB 工具進行實時遷移。

• 水平彈性擴展

  經過簡單地增長新節點便可實現 TiDB 的水平擴展，按需擴展吞吐或存儲，輕鬆應對高併發、海量數據場景。

• 分佈式事務

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

• 真正金融級高可用

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

• 一站式 HTAP 解決方案

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

• 雲原生 SQL 數據庫

  TiDB 是爲雲而設計的數據庫，同 Kubernetes 深度耦合，支持公有云、私有云和混合雲，使部署、配置和維護變得十分簡單。

TiDB 的設計目標是 100% 的 OLTP 場景和 80% 的 OLAP 場景，更復雜的 OLAP 分析能夠經過 TiSpark 項目來完成。

TiDB 對業務沒有任何侵入性，能優雅的替換傳統的數據庫中間件、數據庫分庫分表等 Sharding 方案。同時它也讓開發運維人員不用關注數據庫 Scale 的細節問題，專一於業務開發，極大的提高研發的生產力。

三篇文章瞭解 TiDB 技術內幕：

• 說存儲
• 說計算
• 談調度

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 節點失效，而且在一段時間內（默認 30 分鐘）沒法恢復，PD 會將其上的數據遷移到其餘的 TiKV 節點上。