單節點模式（Standalone，不推薦用于生產環境）
standalone模式即單節點模式，指在服務器上只部署一個 mongod 進程用于讀寫數據。優點是部署簡單，可以快速完成部署，缺點是無容災。只推薦用于日常的開發、測試和學習。
主從復制模式（官方已不建議使用，不推薦用于生產環境）
主從復制模式也比較簡單，包含一個主節點（Primary）和一個或多個從節點（Secondary）。主節點提供讀寫服務，從節點不提供任何服務。也可以修改配置讓從節點提供只讀服務，以減少主節點的壓力，每個從節點會定期輪詢主節點的oplog以保持數據與主節點一致。
這種模式相較于單節點模式，可用性高很多，可用于備份、故障恢復、讀擴展等。缺點是當主節點出現故障時，只能人工介入指定新的主節點（從節點不會自動升級為主節點），并且在這段時間內，集群處于只讀狀態。
副本集模式（Relica Set）
副本集模式包含一個主節點（Primary）和一個或多個從節點（Secondary），這一點與主從復制模式類似且主從節點的作用也類似。相較于主從復制模式，副本集模式的優勢是當主節點發生故障時，副本集可以自動投票產生新的主節點，并引導其余的從節點連接新的主節點。副本集架構如下圖所示：
副本集中各節點通過心跳機制來檢測各自的健康狀況，當主節點出現故障時，多個從節點會觸發選舉操作來選舉其中一個作為新的主節點。為了保證選舉票數不同，副本集的節點數保持為奇數。
在某些情況下(例如只有一個主節點和一個從節點的情況下，由于成本限制不允許添加另一個從節點)，可以選擇向副本集中添加一個仲裁節點（Arbiter）。仲裁節點參與選舉但不會被選為主節點（因為選舉節點沒有數據集的副本）。
分片集群模式（Sharded Cluster）
副本集模式雖然解決了高可用問題，但不能滿足海量數據和需要非常高吞吐的場景。這時候就需要使用到分片技術（sharding，指將數據拆分并分散存儲在不同機器上）了，即分片集群模式。
分片集群模式主要利用了水平擴展的特性，將數據和負載分散到多臺機器上，并根據需要添加額外的服務器以增加容量和提高性能。雖然單臺機器的整體性能或容量可能不高，但每臺機器只是處理總體工作負載的一個單元，集群整體效率可能比單臺性能和容量非常高的機器更高。
搭建一個分片集群需要如下幾個組件：
- shard，每個shard都是一個mongo數據庫實例，包含分片數據的一個子集。一個shard可由幾臺機器組成一個副本集，防止因主節點單點故障導致整個系統崩潰。
- config servers，用于配置服務器存儲集群的元數據和配置設置。
- mongos，在集群中作為查詢路由器，客戶端程序由此接入，讓整個集群看起來像是一個單一的數據庫，提供客戶端應用程序和分片集群之間的接口。mongos本身不保存數據，啟動時從config servers加載集群信息到緩存中，并將客戶端的請求路由給每個shard，聚合各shard返回的結果返回給客戶端。
分片集群內組件間的交互如下圖：
分片集群模式有以下幾個優勢：
- 將讀寫負載分布在集群中的各個分片上，允許每個分片處理集群操作的一個子集。通過添加更多的分片，讀寫工作負載都可以在集群中水平擴展。
- 將數據分布到集群中的各個分片上，允許每個分片包含整個集群數據的一個子集。隨著數據集的增長，額外的分片會增加集群的存儲容量。
- 高可用性，即使一個或多個分片副本集完全不可用，分片集群也可以繼續執行部分讀寫。也就是說，雖然無法訪問不可用分片上的數據，但對可用分片的讀寫仍然可以成功。
小結
本文介紹了MongoDB的四種部署模式：單節點模式和三種集群模式。副本集模式已經替代了主從復制模式，保障了集群的可靠性；分片集群模式的可擴展性，可以滿足海量數據的存儲和高吞吐的需求。生產環境中，不建議使用單實例模式和主從復制模式，副本集模式和分片集模式根據業務場景來選擇。
