一、前言
1、寫在前邊的廢話
最近因工作原因接觸了mysql、mongodb、redis、elasticsearch等幾個數據庫的高可用集羣搭建，深感自己對分佈式數據庫知識的欠缺。特此好好研讀了一下幾個數據庫的集羣搭建原理，出一個系列。
2、真正的前言
Mongodb一共有三種集羣搭建的方式：
Replica Set（副本集）Sharding（切片）Master-Slaver（主從）【目前已不推薦使用了！！！】
二、Mongodb副本集（Replica Sets）
mongodb 不推薦主從複製,推薦建立副本集(Replica Set)來保證1個服務掛了,可以有其他服務頂上,程序正常運行,幾個服務的數據都是一樣的,後臺自動同步。主從複製其實就是一個單副本的應用，沒有很好的擴展性餓容錯性。然而副本集具有多個副本保證了容錯性，就算一個副本掛掉了還有很多個副本存在，並且解決了"主節點掛掉後，整個集羣內會自動切換"的問題。副本集比傳統的Master-Slave主從複製有改進的地方就是它可以進行故障的自動轉移,如果我們停掉複製集中的一個成員,那麼剩餘成員會再自動選舉一個成員,作爲主庫。
Replica Set 使用的是 n 個 mongod 節點,構建具備自動的容錯功能(auto-failover),自動恢復的(auto-recovery)的高可用方案。使用 Replica Set 來實現讀寫分離。通過在連接時指定或者在主庫指定 slaveOk,由Secondary 來分擔讀的壓力,Primary 只承擔寫操作。對於 Replica Set 中的 secondary 節點默認是不可讀的。
1、副本集的結構及原理
MongoDB 的副本集不同於以往的主從模式。在集羣Master故障的時候,副本集可以自動投票,選舉出新的Master,並引導其餘的Slave服務器連接新的Master,而這個過程對於應用是透明的。可以說MongoDB的副本集是自帶故障轉移功能的主從複製。傳統的主從模式,需要手工指定集羣中的 Master。如果 Master 發生故障,一般都是人工介入,指定新的 Master。 這個過程對於應用一般不是透明的,往往伴隨着應用重新修改配置文件,重啓應用服務器等。而 MongoDB 副本集,集羣中的任何節點都可能成爲 Master 節點。一旦 Master 節點故障,則會在其餘節點中選舉出一個新的 Master 節點。 並引導剩餘節點連接到新的 Master 節點。這個過程對於應用是透明的。
一個副本集即爲服務於同一數據集的多個 MongoDB 實例,其中一個爲主節點,其餘的都爲從節點。主節 點上能夠完成讀寫操作,從節點僅能用於讀操作。主節點需要記錄所有改變數據庫狀態的操作,這些記錄 保存在 oplog 中,這個文件存儲在 local 數據庫,各個從節點通過此 oplog 來複制數據並應用於本地,保持 本地的數據與主節點的一致。oplog 具有冪等性,即無論執行幾次其結果一致,這個比 mysql 的二進制日 志更好用。集羣中的各節點還會通過傳遞心跳信息來檢測各自的健康狀況。當主節點故障時,多個從節點會觸發一次 新的選舉操作,並選舉其中的一個成爲新的主節點(通常誰的優先級更高,誰就是新的主節點),心跳信 息默認每 2 秒傳遞一次。
客戶端連接到副本集後，不關心具體哪一臺機器是否掛掉。主服務器負責整個副本集的讀寫，副本集定期同步數據備份。一旦主節點掛掉，副本節點就會選舉一個新的主服務器。這一切對於應用服務器不需要關心。副本集中的副本節點在主節點掛掉後通過心跳機制檢測到後，就會在集羣內發起主節點的選舉機制，自動選舉出一位新的主服務器。副本集包括三種節點:主節點、從節點、仲裁節點。
官方推薦MongoDB副本節點最少爲3臺， 建議副本集成員爲奇數，最多12個副本節點,最多7個節點參與選舉。限制副本節點的數量,主要是因爲一個集羣中過多的副本節點,增加了複製的成本,反而拖累了集羣的整體性能。 太多的副本節點參與選舉,也會增加選舉的時間。而官方建議奇數的節點,是爲了避免腦裂 的發生。
三、Mongodb分片集羣（Sharding）
Sharding cluster是一種可以水平擴展的模式,在數據量很大時特給力,實際大規模應用一般會採用這種架構去構建。sharding分片很好的解決了單臺服務器磁盤空間、內存、cpu等硬件資源的限制問題，把數據水平拆分出去，降低單節點的訪問壓力。每個分片都是一個獨立的數據庫，所有的分片組合起來構成一個邏輯上的完整的數據庫。因此，分片機制降低了每個分片的數據操作量及需要存儲的數據量，達到多臺服務器來應對不斷增加的負載和數據的效果。
1、爲何需要水平分片
1）減少單機請求數,將單機負載,提高總負載
2）減少單機的存儲空間,提高總存空間
2、mongodb sharding 服務器架構
3、分片集羣的構造如下：
分片集羣由以下3個服務組成：
Shards Server: 每個shard由一個或多個mongod進程組成，用於存儲數據
Config Server: 用於存儲集羣的Metadata信息，包括每個Shard的信息和chunks信息
Route Server: 用於提供路由服務，由Client連接，使整個Cluster看起來像單個DB服務器