簡介

MongoDB是一個開源的，基于分布式的，面向文檔存儲的菲關系型數據庫?？梢赃\行在Windows、Unix、OSX、Solaris系統(tǒng)上，支持32位和64位應用，提供多種編程語言的驅動程序。MongoDB支持的數據結構非常松散，是類似JSON的BSON格式，通過鍵值對的形式存儲數據，可以存儲復雜的數據類型。

文檔（document）：文檔是MongoDB的核心概念，是數據的基本單元，類似于關系數據庫中的行。在MongoDB中，文檔表示為鍵值對的一個有序集。文檔一般使用如下的樣式來標記：

從上面的例子可以看到，文檔的值有不同的數據類型，甚至可以是一個完整的內嵌文檔（最后一個示例的author就是一個文檔）

集合（collection）：集合是一組文檔的集合，相當于關系型數據庫中的數據表，MongoDB數據庫不是關系型數據庫，沒有模式的概念。同一集合中的文檔可以有不同的形式。比如：

可以存在同一個集合當中。

數據庫（database）：多個文檔構成集合，多個集合組成數據庫。一個MongoDB實例可以承載多個數據庫，每個數據庫可以擁有0到多個集合。

MongoDB 的主要目標是在鍵值對存儲方式（提供了高性能和高度伸縮性）以及傳統(tǒng)的 RDBMS（關系性數據庫）系統(tǒng)，集兩者的優(yōu)勢于一身。MongoDB適用于以下場景：

• 網站數據：Mongo 非常適合實時的插入，更新與查詢，并具備網站實時數據存儲所需的復制及高度伸縮性。

• 緩存：由于性能很高，Mongo 也適合作為信息基礎設施的緩存層。在系統(tǒng)重啟之后，由 Mongo 搭建的持久化緩存可以避免下層的數據源過載。 

• 大尺寸、低價值的數據：使用傳統(tǒng)的關系數據庫存儲一些數據時可能會比較貴，在此之前，很多程序員往往會選擇傳統(tǒng)的文件進行存儲。

• 高伸縮性的場景：Mongo非常適合由數十或數百臺服務器組成的數據庫

• 用于對象及JSON數據的存儲：Mongo的BSON數據格式非常適合文檔格式化的存儲及查詢。

當然 MongoDB 也有不適合的場景：

• 高度事務性的系統(tǒng)：例如銀行或會計系統(tǒng)。傳統(tǒng)的關系型數據庫目前還是更適用于需要大量事務的應用程序。

• 傳統(tǒng)的商業(yè)智能應用：針對特定問題的 BI 數據庫能夠提供高度優(yōu)化的查詢方式。對于此類應用，數據倉庫可能時更適合的選擇（如Hadoop套件中的Hive）。

• 需要SQL的問題。  

集群攻略

MongoDB在商用環(huán)境中，為了高可用性，通常都是以集群形式使用的，MongoDB的集群環(huán)境搭建非常簡單，下面就作一個介紹。 

我們在使用MySQL數據庫時廣泛采用的模式，采用雙機備份后主節(jié)點掛掉了后從節(jié)點可以接替主機繼續(xù)服務。所以這種模式比單節(jié)點的要可靠得多。

下面看一下怎么一步步搭建MongoDB的主從復制節(jié)點：

1. 準備兩臺機器 10.43.159.56 和 10.43.159.58。 10.43.159.56當作主節(jié)點， 10.43.159.58作為從節(jié)點。

2. 分別下載MongoDB安裝程序包。在10.43.159.56上建立文件夾/data/MongoDBtest/master，10.43.159.58建立文件夾/data/MongoDBtest/slave。

3. 在10.43.159.56啟動MongoDB主節(jié)點程序。注意后面的這個 “ –master ”參數，標示主節(jié)點：

輸出日志如下，成功：

4. 在10.43.159.58啟動MongoDB從節(jié)點程序。關鍵配置：指定主節(jié)點ip地址和端口 –source 10.43.159.56:27017 和標示從節(jié)點 –slave參數：

輸出日志如下，成功：

日志顯示從節(jié)點從主節(jié)點同步復制數據 ：

這樣，主從結構的MongoDB集群就搭建好了，是不是很簡單？

下面我們來看看這個集群能做什么？先登錄到從節(jié)點shell上，執(zhí)行插入數據：

可以看到 MongoDB的從節(jié)點是只能讀，不能執(zhí)行寫操作的。

那么如果主服務器掛掉，從服務器可以接替工作嗎？

可以試一下，強制關掉主節(jié)點上的MongoDB進程，登錄在從節(jié)點上，再次執(zhí)行插入數據：

看來從節(jié)點并沒有自動接替主節(jié)點的工作，那就只有人工處理了，停止從節(jié)點，再以master的方式啟動從節(jié)點，由于從節(jié)點上數據跟主節(jié)點一樣，此時從節(jié)點是可以替代主節(jié)點工作的，這屬于人工切換。

此外，我們可以搭建多個從節(jié)點，實現數據庫的讀寫分離，比如主節(jié)點負責寫，多個從節(jié)點負責讀，對于移動APP，絕大部分操作都是讀操作，可以實現負荷分擔。 

那么，搭建了這套主從結構的集群是不是就能應付商用環(huán)境呢？我們發(fā)現還是有幾個問題亟待解決的：

• 主節(jié)點掛了能否自動切換連接？目前需要手工切換。

• 主節(jié)點的寫壓力過大如何解決？

• 從節(jié)點每個上面的數據都是對數據庫全量拷貝，從節(jié)點壓力會不會過大？

• 就算對從節(jié)點路由實施路由訪問策略能否做到自動擴展？

解決這幾個問題就要靠下面介紹的副本集模式了。 

MongoDB官方已經不建議使用主從模式了，替代方案是采用副本集的模式，那什么是副本集呢？簡單地說，副本集就是有自動故障恢復功能的主從集群，或者說主從模式其實就是一個單副本的應用，沒有很好的擴展性和容錯性。而副本集具有多個副本保證了容錯性，就算一個副本掛掉了還有很多副本存在，更棒的是副本集很多地方都是自動化的，它為你做了很多管理工作。聰明的讀者已經發(fā)現，主從模式的第一個問題手工切換已經得到解決了，難怪MongoDB官方強烈推薦使用這種模式。我們來看看MongoDB副本集的架構圖：

由圖可以看到客戶端連接到整個副本集，不關心具體哪一臺機器是否掛掉。主服務器負責整個副本集的讀寫，副本集定期同步數據備份，一旦主節(jié)點掛掉，副本節(jié)點就會選舉一個新的主服務器，這一切對于應用服務器不需要關心。我們看一下主服務器掛掉后的架構：

副本集中的副本節(jié)點通過心跳機制檢測到主節(jié)點掛掉后，就會在集群內發(fā)起主節(jié)點的選舉機制，自動選舉一位新的主服務器。So Cool！讓我們趕緊來部署一下！

官方推薦的副本集機器數量為至少3個（官方說副本集數量最好是奇數），那我們也按照這個數量配置測試。

1. 準備三臺機器 10.43.159.56、 10.43.159.58、10.43.159.60。10.43.159.56當作副本集主節(jié)點，10.43.159.58、10.43.159.60作為副本集副本節(jié)點。

2. 分別在每臺機器上建立MongoDB副本集測試文件夾

3. 下載安裝MongoDB的安裝程序包

4. 分別在每臺機器上啟動MongoDB

給你的副本集取個名字吧，比如這里叫test：

從日志可以看出副本集還沒有初始化。 

5. 初始化副本集

在三臺機器上任意一臺機器登陸MongoDB：

使用admin數據庫：

定義副本集配置變量，這里的 _id:”test” 和上面命令參數“ –replSet test” 要保持一致：

初始化副本集配置：

輸出成功：

查看日志，副本集啟動成功后，56為主節(jié)點PRIMARY，58、60為副本節(jié)點SECONDARY，注意這里是三個節(jié)點共同選舉出的主節(jié)點，有一定隨機性。

查看集群節(jié)點的狀態(tài)：

整個副本集已經搭建成功了。是不是超級簡單？ 

副本集模式的MongoDB不僅搭建簡單，而且功能強大?，F在回頭看看這種模式能否解決我們前面遺留的問題：主節(jié)點掛了能否自動切換連接？

先測試副本集數據復制功能是否正常

首先在主節(jié)點56上插入數據，然后再副本節(jié)點上查看數據，發(fā)現日志報錯：

這是因為默認只從主節(jié)點讀寫數據，副本不允許讀，只要設置副本可以讀即可。在副本節(jié)點上執(zhí)行：rs.slaveOk()，然后查詢數據，發(fā)現主節(jié)點的數據已經同步過來了。 

再測試下副本集的故障轉移功能

先停掉主節(jié)點56上的進程，可以看到58和60節(jié)點上的日志顯示的就是投票過程。再執(zhí)行rs.status()可以看到集群狀態(tài)更新了，56為不可達，58成為主節(jié)點，60還是副本。再啟動56節(jié)點，發(fā)現還是58為主節(jié)點，56變?yōu)楦北竟?jié)點。這樣就解決了第一個故障自動轉移的問題。

那么，對于主節(jié)點讀寫壓力過大，如何解決呢？常見的解決方案是讀寫分離，MongoDB副本集的讀寫分離如何做呢？

看圖說話：

對于移動APP的場景，通常寫操作遠沒有讀操作多，所以一臺主節(jié)點負責寫，兩臺副本節(jié)點負責讀。從哪個節(jié)點讀，完全可以由客戶端選擇，數據讀取參數一共有五類（Primary、PrimaryPreferred、Secondary、SecondaryPreferred、Nearest）：

• Primary：默認參數，只從主節(jié)點上進行讀取操作； 

• PrimaryPreferred：大部分從主節(jié)點上讀取數據，只有主節(jié)點不可用時從Secondary節(jié)點讀取數據。 

• Secondary：只從Secondary節(jié)點上進行讀取操作，存在的問題是Secondary節(jié)點的數據會比Primary節(jié)點數據“舊”。 

• SecondaryPreferred：優(yōu)先從Secondary節(jié)點進行讀取操作，Secondary節(jié)點不可用時從主節(jié)點讀取數據； 

• Nearest：不管是主節(jié)點、Secondary節(jié)點，從網絡延遲最低的節(jié)點上讀取數據。

典型的副本集組網中，除了有副本節(jié)點，還有其他角色，比如仲裁節(jié)點，如下圖： 

其中的仲裁節(jié)點不存儲數據，只是負責故障轉移的群體投票，這樣就少了數據復制的壓力。此外還有Secondary-Only、Hidden、Delayed、Non-Voting等角色。

Secondary-Only：不能成為Primary節(jié)點，只能作為Secondary副本節(jié)點，防止一些性能不高的節(jié)點成為主節(jié)點。 
Hidden：這類節(jié)點是不能夠被客戶端制定IP引用，也不能被設置為主節(jié)點，但是可以投票，一般用于備份數據。 
Delayed：可以指定一個時間延遲從Primary節(jié)點同步數據。主要用于備份數據，如果實時同步，誤刪除數據馬上同步到從節(jié)點，恢復又恢復不了。 
Non-Voting：沒有選舉權的Secondary節(jié)點，純粹的備份數據節(jié)點。

到此整個MongoDB副本集搞定了兩個問題：

• 主節(jié)點掛了能否自動切換連接？    //咱用副本集

• 主節(jié)點的讀寫壓力過大如何解決？ //讀寫分離

還有兩個問題待后續(xù)解決：

• 從節(jié)點每個上面的數據都是對數據庫全量拷貝，從節(jié)點壓力會不會過大？

• 如果數據壓力大到機器支撐不了的時候能否做到自動擴展？

這個可以通過MongoDB的分片功能來解決，我們下次再說。Bye Bye！