簡介

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

基本概念

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

{"title":"hello!"} 
{"title":"hello!","recommend":5} 
{"title":"hello!","recommend":5,"author":{"firstname":"paul","lastname":"frank"}}  

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

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

{"name":"jack","age":19} 
 
{"name":"wangjun","age":22,"sex":"1"}  

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

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

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

• 網站數據：Mongo 非常適合實時的插入，更新與查詢，并具備網站實時數據存儲所需的復制及高度伸縮性。
• 緩存：由于性能很高，Mongo 也適合作為信息基礎設施的緩存層。在系統重啟之后，由 Mongo 搭建的持久化緩存可以避免下層的數據源過載。 
• 大尺寸、低價值的數據：使用傳統的關系數據庫存儲一些數據時可能會比較貴，在此之前，很多程序員往往會選擇傳統的文件進行存儲。
• 高伸縮性的場景：Mongo非常適合由數十或數百臺服務器組成的數據庫
• 用于對象及JSON數據的存儲：Mongo的BSON數據格式非常適合文檔格式化的存儲及查詢。

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

• 高度事務性的系統：例如銀行或會計系統。傳統的關系型數據庫目前還是更適用于需要大量事務的應用程序。
• 傳統的商業智能應用：針對特定問題的 BI 數據庫能夠提供高度優化的查詢方式。對于此類應用，數據倉庫可能時更適合的選擇（如Hadoop套件中的Hive）。
• 需要SQL的問題。  

集群攻略

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

主從模式

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

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

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

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

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

mongod –dbpath /data/MongoDBtest/master–master 

輸出日志如下，成功： 

[initandlisten] MongoDB starting :pid=18285 port=27017 dbpath=/data/MongoDBtest/master master=1 

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

mongod –dbpath /data/MongoDBtest/slave–slave –source 10.43.159.56:27017 

輸出日志如下，成功： 

[initandlisten] MongoDB starting : pid=17888port=27017 dbpath=/data/MongoDBtest/slave slave=1  

日志顯示從節點從主節點同步復制數據 ： 

[replslave] repl: from host: 10.43.159.56:27017 

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

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

mongo 127.0.0.1:27017   
 
> db.testdb.insert({"test3":"testval3"});   
 
not master    

可以看到 MongoDB的從節點是只能讀，不能執行寫操作的。

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

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

> db.testdb.insert({"test3":"testval3"});   
 
not master    

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

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

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

• 主節點掛了能否自動切換連接？目前需要手工切換。
• 主節點的寫壓力過大如何解決？
• 從節點每個上面的數據都是對數據庫全量拷貝，從節點壓力會不會過大？
• 就算對從節點路由實施路由訪問策略能否做到自動擴展？

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

副本模式

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

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

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

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

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

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

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

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

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

/data/MongoDBtest/MongoDB-linux-x86_64-2.4.8/bin/mongod  --dbpath /data/MongoDBtest/replset/data   --replSet test 

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

5. 初始化副本集

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

/data/MongoDBtest/MongoDB-linux-x86_64-2.4.8/bin/mongo 

使用admin數據庫： 

use admin 

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

config = { _id:"test", members:[ 
 
... {_id:0,host:" 10.43.159.56:27017"}, 
 
... {_id:1,host:" 10.43.159.58:27017"}, 
 
... {_id:2,host:" 10.43.159.60:27017"}] 
 
... }  

初始化副本集配置： 

rs.initiate(config); 

輸出成功： 

{   
 
    "info" : "Config now saved locally.  Should come online in about a minute.",   
 
    "ok" : 1   
 
}    

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

查看集群節點的狀態： 

rs.status(); 

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

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

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

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

error: { "$err" : "not master and slaveOk=false", "code" : 13435 } at src/mongo/shell/query.js:128 

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

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

先停掉主節點56上的進程，可以看到58和60節點上的日志顯示的就是投票過程。再執行rs.status()可以看到集群狀態更新了，56為不可達，58成為主節點，60還是副本。再啟動56節點，發現還是58為主節點，56變為副本節點。這樣就解決了***個故障自動轉移的問題。

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

看圖說話：

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

• Primary：默認參數，只從主節點上進行讀取操作； 
• PrimaryPreferred：大部分從主節點上讀取數據，只有主節點不可用時從Secondary節點讀取數據。 
• Secondary：只從Secondary節點上進行讀取操作，存在的問題是Secondary節點的數據會比Primary節點數據“舊”。 
• SecondaryPreferred：優先從Secondary節點進行讀取操作，Secondary節點不可用時從主節點讀取數據； 
• Nearest：不管是主節點、Secondary節點，從網絡延遲***的節點上讀取數據。

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

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

Secondary-Only：不能成為Primary節點，只能作為Secondary副本節點，防止一些性能不高的節點成為主節點。 

Hidden：這類節點是不能夠被客戶端制定IP引用，也不能被設置為主節點，但是可以投票，一般用于備份數據。 

Delayed：可以指定一個時間延遲從Primary節點同步數據。主要用于備份數據，如果實時同步，誤刪除數據馬上同步到從節點，恢復又恢復不了。 

Non-Voting：沒有選舉權的Secondary節點，純粹的備份數據節點。

總結及思考

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

• 主節點掛了能否自動切換連接？    //咱用副本集
• 主節點的讀寫壓力過大如何解決？ //讀寫分離

還有兩個問題待后續解決：

• 從節點每個上面的數據都是對數據庫全量拷貝，從節點壓力會不會過大？
• 如果數據壓力大到機器支撐不了的時候能否做到自動擴展？

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