轉載：http://c.biancheng.net/view/6567.html
本節我們從理論上講解 MongoDB 分布式集群架構的三種模式，下節《將MongoDB部署到分布式集群（實操）》我們會使用三台機器實際部署 MongoDB，帶着大家實踐一把，光說不練假把式。
MongoDB 有三種集群部署模式，分別為主從復制（Master-Slaver）、副本集（Replica Set）和分片（Sharding）模式。
- Master-Slaver 是一種主從副本的模式，目前已經不推薦使用。
- Replica Set 模式取代了 Master-Slaver 模式，是一種互為主從的關系。Replica Set 將數據復制多份保存，不同服務器保存同一份數據，在出現故障時自動切換，實現故障轉移，在實際生產中非常實用。
- Sharding 模式適合處理大量數據，它將數據分開存儲，不同服務器保存不同的數據，所有服務器數據的總和即為整個數據集。
Sharding 模式追求的是高性能，而且是三種集群中最復雜的。在實際生產環境中，通常將 Replica Set 和 Sharding 兩種技術結合使用。
主從復制
雖然 MongoDB 官方建議用副本集替代主從復制，但是本節還是從主從復制入手，讓大家了解 MongoDB 的復制機制。
主從復制是 MongoDB 中最簡單的數據庫同步備份的集群技術，其基本的設置方式是建立一個主節點（Primary）和一個或多個從節點（Secondary），如下圖所示。
這種方式比單節點的可用性好很多，可用於備份、故障恢復、讀擴展等。集群中的主從節點均運行 MongoDB 實例，完成數據的存儲、查詢與修改操作。
主從復制模式的集群中只能有一個主節點，主節點提供所有的增、刪、查、改服務，從節點不提供任何服務，但是可以通過設置使從節點提供查詢服務，這樣可以減少主節點的壓力。
另外，每個從節點要知道主節點的地址，主節點記錄在其上的所有操作，從節點定期輪詢主節點獲取這些操作，然后對自己的數據副本執行這些操作，從而保證從節點的數據與主節點一致。
在主從復制的集群中，當主節點出現故障時，只能人工介入，指定新的主節點，從節點不會自動升級為主節點。同時，在這段時間內，該集群架構只能處於只讀狀態。
副本集
副本集的集群架構如下圖所示。
此集群擁有一個主節點和多個從節點，這一點與主從復制模式類似，且主從節點所負責的工作也類似，但是副本集與主從復制的區別在於：當集群中主節點發生故障時，副本集可以自動投票，選舉出新的主節點，並引導其余的從節點連接新的主節點，而且這個過程對應用是透明的。
可以說，MongoDB 的副本集是自帶故障轉移功能的主從復制。
MongoDB 副本集使用的是 N 個 mongod 節點構建的具備自動容錯功能、自動恢復功能的高可用方案。在副本集中，任何節點都可作為主節點，但為了維持數據一致性，只能有一個主節點。
主節點負責數據的寫入和更新，並在更新數據的同時，將操作信息寫入名為 oplog 的日志文件當中。主節點還負責指定其他節點為從節點，並設置從節點數據的可讀性，從而讓從節點來分擔集群讀取數據的壓力。
另外，從節點會定時輪詢讀取 oplog 日志，根據日志內容同步更新自身的數據，保持與主節點一致。
在一些場景中，用戶還可以使用副本集來擴展讀性能，客戶端有能力發送讀寫操作給不同的服務器，也可以在不同的數據中心獲取不同的副本來擴展分布式應用的能力。
在副本集中還有一個額外的仲裁節點（不需要使用專用的硬件設備），負責在主節點發生故障時，參與選舉新節點作為主節點。
副本集中的各節點會通過心跳信息來檢測各自的健康狀況，當主節點出現故障時，多個從節點會觸發一次新的選舉操作，並選舉其中一個作為新的主節點。為了保證選舉票數不同，副本集的節點數保持為奇數。
分片
副本集可以解決主節點發生故障導致數據丟失或不可用的問題，但遇到需要存儲海量數據的情況時，副本集機制就束手無策了。副本集中的一台機器可能不足以存儲數據，或者說集群不足以提供可接受的讀寫吞吐量。這就需要用到 MongoDB 的分片（Sharding）技術，這也是 MongoDB 的另外一種集群部署模式。
分片是指將數據拆分並分散存放在不同機器上的過程。有時也用分區來表示這個概念。將數據分散到不同的機器上，不需要功能強大的大型計算機就可以存儲更多的數據，處理更大的負載。
MongoDB 支持自動分片，可以使數據庫架構對應用程序不可見，簡化系統管理。對應用程序而言，就如同始終在使用一個單機的 MongoDB 服務器一樣。
MongoDB 的分片機制允許創建一個包含許多台機器的集群，將數據子集分散在集群中，每個分片維護着一個數據集合的子集。與副本集相比，使用集群架構可以使應用程序具有更強大的數據處理能力。
MongoDB 分片的集群模式如下圖所示。
構建一個 MongoDB 的分片集群，需要三個重要的組件，分別是分片服務器（Shard Server）、配置服務器（Config Server）和路由服務器（Route Server）。
Shard Server
每個 Shard Server 都是一個 mongod 數據庫實例，用於存儲實際的數據塊。整個數據庫集合分成多個塊存儲在不同的 Shard Server 中。
在實際生產中，一個 Shard Server 可由幾台機器組成一個副本集來承擔，防止因主節點單點故障導致整個系統崩潰。
Config Server
這是獨立的一個 mongod 進程，保存集群和分片的元數據，在集群啟動最開始時建立，保存各個分片包含數據的信息。
Route Server
這是獨立的一個 mongos 進程，Route Server 在集群中可作為路由使用，客戶端由此接入，讓整個集群看起來像是一個單一的數據庫，提供客戶端應用程序和分片集群之間的接口。
Route Server 本身不保存數據，啟動時從 Config Server 加載集群信息到緩存中，並將客戶端的請求路由給每個 Shard Server，在各 Shard Server 返回結果后進行聚合並返回客戶端。
以上介紹了 MongoDB 的三種集群模式，副本集已經替代了主從復制，通過備份保證集群的可靠性，分片機制為集群提供了可擴展性，以滿足海量數據的存儲和分析的需求。
在實際生產環境中，副本集和分片是結合起來使用的，可滿足實際應用場景中高可用性和高可擴展性的需求。