簡介

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

基本概念

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

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

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

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

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

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

數(shù)據(jù)庫（database）：多個文檔構(gòu)成集合，多個集合組成數(shù)據(jù)庫。一個MongoDB實例可以承載多個數(shù)據(jù)庫，每個數(shù)據(jù)庫可以擁有0到多個集合。

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

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

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

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

集群攻略

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

主從模式

我們在使用MySQL數(shù)據(jù)庫時廣泛采用的模式，采用雙機備份后主節(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 ”參數(shù)，標示主節(jié)點： 

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從節(jié)點程序。關(guān)鍵配置：指定主節(jié)點ip地址和端口 –source 10.43.159.56:27017 和標示從節(jié)點 –slave參數(shù)： 

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

輸出日志如下，成功： 

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

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

[replslave] repl: from host: 10.43.159.56:27017 

這樣，主從結(jié)構(gòu)的MongoDB集群就搭建好了，是不是很簡單？

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

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

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

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

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

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

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

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

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

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

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

副本模式

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

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

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

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

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： 

/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數(shù)據(jù)庫： 

use admin 

定義副本集配置變量，這里的 _id:”test” 和上面命令參數(shù)“ –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為主節(jié)點PRIMARY，58、60為副本節(jié)點SECONDARY，注意這里是三個節(jié)點共同選舉出的主節(jié)點，有一定隨機性。

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

rs.status(); 

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

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

先測試副本集數(shù)據(jù)復制功能是否正常

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

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

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

再測試下副本集的故障轉(zhuǎn)移功能

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

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

看圖說話：

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

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

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

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

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

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

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

Non-Voting：沒有選舉權(quán)的Secondary節(jié)點，純粹的備份數(shù)據(jù)節(jié)點。

總結(jié)及思考

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

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

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

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

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