此文已由作者溫正湖授權網易雲社群釋出。

歡迎訪問網易雲社群，瞭解更多網易技術產品運營經驗。

最近閱讀了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+款雲產品！ 

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