摘要：此文已由作者溫正湖授權網易云社區發布。分片集群通過就可以實現負載均衡，不需要多帶帶部署負載均衡組件。是一個集群，通過協議保持數據的一致性副本數量可配置，默認保存三副本，并通過做負載均衡調度。

此文已由作者溫正湖授權網易云社區發布。

歡迎訪問網易云社區，了解更多網易技術產品運營經驗。

最近閱讀了TiDB源碼的說明文檔，跟MongoDB的分片集群做了下簡單對比。

首先展示TiDB的整體架構

MongoDB分片集群架構如下：

更加具體點如下：

下面從介紹TiDB組件的角度切入，將其跟MongoDB分片集群做對比。

TiDB 集群主要分為三個組件：

TiDB Server

TiDB Server 負責接收 SQL 請求，處理 SQL 相關的邏輯，并通過 PD 找到存儲計算所需數據的 TiKV 地址，與 TiKV 交互獲取數據，最終返回結果。 TiDB Server 是無狀態的，其本身并不存儲數據，只負責計算，可以無限水平擴展，可以通過負載均衡組件（如LVS、HAProxy 或 F5）對外提供統一的接入地址。

// 類比MongoDB分片集群中的mongos或者叫router server

PD Server

Placement Driver (簡稱 PD) 是整個集群的管理模塊，其主要工作有三個： 一是存儲集群的元信息（某個 Key 存儲在哪個 TiKV 節點）；二是對 TiKV 集群進行調度和負載均衡（如數據的遷移、Raft group leader 的遷移等）；三是分配全局唯一且遞增的事務 ID。

PD 是一個集群，需要部署奇數個節點，一般線上推薦至少部署 3 個節點。

//類比MongoDB分片集群中的config server

TiKV Server

TiKV Server 負責存儲數據，從外部看 TiKV 是一個分布式的提供事務的 Key-Value 存儲引擎。存儲數據的基本單位是 Region，每個 Region 負責存儲一個 Key Range （從 StartKey 到 EndKey 的左閉右開區間）的數據，每個 TiKV 節點會負責多個 Region 。TiKV 使用 Raft 協議做復制，保持數據的一致性和容災。副本以 Region 為單位進行管理，不同節點上的多個 Region 構成一個 Raft Group，互為副本。數據在多個 TiKV 之間的負載均衡由 PD 調度，這里也是以 Region 為單位進行調度。

//類比MongoDB分片集群中的replica set

// Region概念類似MongoDB分片中的chunk，但又有些不一樣。chunk是個邏輯概念，數據存儲并不是以chunk為單位。而Region是正式在TIKV上的數據單位。兩種都是數據遷移的最小單位。默認也是64MB

核心特性

水平擴展

無限水平擴展是 TiDB 的一大特點，這里說的水平擴展包括兩方面：計算能力和存儲能力。TiDB Server 負責處理 SQL 請求，隨著業務的增長，可以簡單的添加 TiDB Server 節點，提高整體的處理能力，提供更高的吞吐。TiKV 負責存儲數據，隨著數據量的增長，可以部署更多的 TiKV Server 節點解決數據 Scale 的問題。PD 會在 TiKV 節點之間以 Region 為單位做調度，將部分數據遷移到新加的節點上。所以在業務的早期，可以只部署少量的服務實例（推薦至少部署 3 個 TiKV， 3 個 PD，2 個 TiDB），隨著業務量的增長，按照需求添加 TiKV 或者 TiDB 實例。

// TIDB相比MongoDB分片，優勢在于其具有更強的業務負載均衡的能力，TIDB是每個region作為一個raft group，會根據raft group leader所在TIKV節點的負載來調整leader節點，從而實現業務負載均衡。

高可用

高可用是 TiDB 的另一大特點，TiDB/TiKV/PD 這三個組件都能容忍部分實例失效，不影響整個集群的可用性。下面分別說明這三個組件的可用性、單個實例失效后的后果以及如何恢復。

TiDB

TiDB 是無狀態的，推薦至少部署兩個實例，前端通過負載均衡組件對外提供服務。當單個實例失效時，會影響正在這個實例上進行的 Session，從應用的角度看，會出現單次請求失敗的情況，重新連接后即可繼續獲得服務。單個實例失效后，可以重啟這個實例或者部署一個新的實例。

// MongoDB分片集群通過Driver就可以實現負載均衡，不需要多帶帶部署負載均衡組件。 Driver同時連接多個mongos實現負載均衡。

PD

PD 是一個集群，通過 Raft 協議保持數據的一致性，單個實例失效時，如果這個實例不是 Raft 的 leader，那么服務完全不受影響；如果這個實例是 Raft 的 leader，會重新選出新的 Raft leader，自動恢復服務。PD 在選舉的過程中無法對外提供服務，這個時間大約是3秒鐘。推薦至少部署三個 PD 實例，單個實例失效后，重啟這個實例或者添加新的實例。

// 跟config server的高可用一樣，但config server心跳超時需要10s，選出主一般需要30s時間。由于mongos緩存了cs上的元數據，所以cs選主期間，業務正常的讀寫均不受影響。很好奇，選主如何在3s之內搞定。

TiKV

TiKV 是一個集群，通過 Raft 協議保持數據的一致性（副本數量可配置，默認保存三副本），并通過 PD 做負載均衡調度。單個節點失效時，會影響這個節點上存儲的所有 Region。對于 Region 中的 Leader 結點，會中斷服務，等待重新選舉；對于 Region 中的 Follower 節點，不會影響服務。當某個 TiKV 節點失效，并且在一段時間內（默認 10 分鐘）無法恢復，PD 會將其上的數據遷移到其他的 TiKV 節點上。

// 這是TiDB相比MongoDB分片的不同的地方，PD在某個TiKV節點失效超時后，將其上原有的數據副本遷移到其他存活的TiKV節點實現數據副本完整性。而MongoDB分片集群的數據高可用依賴shard的配置，如果shard是單一的mongod進程，那么該shard故障后，其上的數據都不可用或丟失，如果shard是復制集，則數據是安全的，但副本數會減少，需要人工處理故障節點。所以，分片集群中shard一定要配置為復制集的形式

網易云免費體驗館，0成本體驗20+款云產品！

更多網易技術、產品、運營經驗分享請點擊。

文章來源： 網易云社區