此文已由作者溫正湖授權網易雲社群釋出。
歡迎通路網易雲社群，了解更多網易技術産品營運經驗。
最近閱讀了TiDB源碼的說明文檔，跟MongoDB的分片叢集做了下簡單對比。
首先展示TiDB的整體架構
下面從介紹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+款雲産品！
更多網易技術、産品、營運經驗分享請點選。
相關文章：
【推薦】 BigData – Join中竟然也有謂詞下推!?