什么是分布式數據庫和TIDB 整體架構

這篇文章給大家介紹什么是分布式數據庫和TIDB 整體架構，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

TIDB 是一個分布式，強一致的可水平擴展的關系型數據庫，在TIDB 設計之初，聚焦了四個設計的要點

1  水平擴展， 在設計之初水平擴展是最基本的需求，通過添加機器的方式擴展，存儲的能力和計算的能力

2  高可用， TIDB 作為分布式數據庫，節點眾多，對于節點失效和數據庫滾動升級，需要解決少量節點失效的問題

3  ACID 事務， 雖然部分數據庫為了更高效的存儲和處理數據，拋棄了SQL和事務，但在生產中的交易場景中，事務是非常重要的，另一個主要的原因在于如果事務的問題不在本地存儲，而是業務解決或者中間件解決，這樣做比較難做到高效

4 SQL 支持，提供MYSQL 的支持，讓整體使用數據庫變得簡單

下面是一張TIDB 的結構圖

TIDB 存儲引擎是TIKV 數據庫存儲引擎，采用了分層的架構來實現

1 transaction

2 MVCC

3 raft

4 local kv storage

容災與特點

高度分層，底層為ROCKSDB，通過raft來進行數據存儲的高可用， 高度分層的主要原因是可以更獨立的進行層次的切換。通過多副本的方式進行數據的存儲，通過raft 進行強一致，多個副本中只有一個leader 其他節點為follower，其中leader 和follower值不固定的，在leader失效后，會選擇follower通過算法變為leader的角色變換。

Raft 本身是支持一份數據的強一致的多副本，分布式數據如何切片，如何將不同的切片放到不同的位置上，這就需要一個分片的算法，基于hash的分片，或者基于range 劃分，但由于數據庫在查詢中會涉及到一段連續值的查詢的可能，則利用range分片比較合理。將存儲KEY 的空間進行切分，主要根據KEY VALUE存儲的閾值來進行，默認96MB進行數據的切分。

下圖是一個多節點中某個節點 region 從節點 1 到 節點4的過程

則問題是在數據的遷移中，誰主導了整體遷移的操控，Placement Driver集群主導了。

具體可以看上圖，另外在事務模型中，PD 的leader 會根據時間算法提供時間戳，作為事務的標簽，整體以去中心化為設計理念。在TIDB 中3.0前以樂觀鎖為鎖的設計，在數據事務處理中并不會上鎖，而是在提交的過程中上鎖。3.0提供了悲觀鎖，類似傳統數據庫的鎖設計。

3 TIDB SQL 引擎

下圖是一張TIDB SQL 層的整體的圖形。

整體的SQL 處理流程， 如果是計算 COUNT ， 則TIDB PD獲知這些數據在那個 region 中，region 根據where 條件，將符合的條件的數據進行累加和，最終每個region將自己的累加和匯總到 TIDB SERVER ,在進行聚合SUM。

4  DDL 在線修改，TIDB 根據  f1-schema-change 的思想來設計整體DDL 操作。具體可以參考下面的文檔，總結出幾句話

1 給與修改DDL 操作一個時間范圍

2 在DDL 操作中，每個region都會提供兩種狀態,可以刪除和可寫狀態

3 租約的概念，在系統中設定的租約到期后，需要重載SCHEMA

關于什么是分布式數據庫和TIDB 整體架構就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。