盧至彤,李 翀,柯 勇,孫健英

(中國(guó)科學(xué)院 計(jì)算機(jī)網(wǎng)絡(luò)信息中心,北京 100190)

一種MongoDB應(yīng)用優(yōu)化策略①

盧至彤,李 翀,柯 勇,孫健英

(中國(guó)科學(xué)院 計(jì)算機(jī)網(wǎng)絡(luò)信息中心,北京 100190)

為了解決不斷增長(zhǎng)的文件存儲(chǔ)需求,和高流量高并發(fā)的訪問(wèn)量,增強(qiáng)系統(tǒng)的響應(yīng)性能,提出一種Web應(yīng)用優(yōu)化策略,通過(guò)MongoDB GridFS對(duì)網(wǎng)站文件存儲(chǔ)容量、可用性和可靠性進(jìn)行擴(kuò)展,并且通過(guò)Nginx和Keepalived,對(duì)后臺(tái)訪問(wèn)進(jìn)行負(fù)載均衡和雙機(jī)熱備,優(yōu)化并發(fā)性能.實(shí)驗(yàn)表明,當(dāng)并發(fā)訪問(wèn)數(shù)上升至80以上時(shí),平均訪問(wèn)響應(yīng)時(shí)間縮短9%.文件通過(guò)Nginx Gridfs進(jìn)行高并發(fā)上傳時(shí)非常穩(wěn)定,在較大文件下載時(shí)比直接通過(guò)本地文件系統(tǒng)EXT4下載速度更高.

MongoDB;GridFS;Nginx;Keepalived;concurrency

Web應(yīng)用通過(guò)文件服務(wù)器對(duì)圖片、視頻和文檔資源對(duì)文件進(jìn)行管理,包括:文件存儲(chǔ)、文件同步和文件訪問(wèn).對(duì)于大多數(shù)應(yīng)用而言,需要文件系統(tǒng)來(lái)存儲(chǔ)用戶上傳的文件.一般而言,用戶上傳的單個(gè)文件所占用的空間一般不大,但是上傳的文件數(shù)量是在不斷快速增長(zhǎng)的.單機(jī)文件系統(tǒng)存儲(chǔ)容量可能會(huì)超過(guò)單機(jī)硬盤(pán)的擴(kuò)容范圍而且其查詢性能在存儲(chǔ)量級(jí)過(guò)大時(shí)查找和插入性能都可能會(huì)遇到瓶頸.我們可以采用MongoDB GridFS[1]分布式文件系統(tǒng)來(lái)達(dá)到我們動(dòng)態(tài)增加存儲(chǔ)容量的目的.

除此以外,MongoDB GridFS分布式文件系統(tǒng)能夠自動(dòng)進(jìn)行冗余備份,保證用戶的文件不會(huì)丟失;還有高可用性,也就是說(shuō)當(dāng)某個(gè)文件服務(wù)器出現(xiàn)故障的時(shí)候,自動(dòng)切換到備份提供服務(wù),使用戶感覺(jué)不到有什么異常.

隨著Web應(yīng)用訪問(wèn)量的提高,我們可以通過(guò)Nginx反向代理服務(wù)器的負(fù)載均衡來(lái)提升Web應(yīng)用的響應(yīng)性能.對(duì)于負(fù)載均衡集群架構(gòu)系統(tǒng),各服務(wù)器間需要共享session信息,我們可以通過(guò)Memcache[2]這個(gè)高性能的分布式的內(nèi)存對(duì)象緩存系統(tǒng)來(lái)解決這個(gè)問(wèn)題.

本文通過(guò)MongoDB GridFS分布式文件系統(tǒng)對(duì)網(wǎng)站文件存儲(chǔ)容量、可用性和讀取性能進(jìn)行擴(kuò)展.通過(guò)Nginx[3]代理服務(wù)器大量的并發(fā)訪問(wèn)或數(shù)據(jù)流量分擔(dān)到多臺(tái)節(jié)點(diǎn)設(shè)備上分別處理,減少用戶等待響應(yīng)的時(shí)間,優(yōu)化并發(fā)性能.

1 系統(tǒng)設(shè)計(jì)

系統(tǒng)設(shè)計(jì)架構(gòu)示意圖如圖1所示,系統(tǒng)通過(guò)Nginx代理服務(wù)器實(shí)現(xiàn)對(duì)于業(yè)務(wù)服務(wù)器和文件服務(wù)器集群的訪問(wèn),其中系統(tǒng)使用兩臺(tái)代理服務(wù)器采用雙機(jī)熱備技術(shù)確保系統(tǒng)的可靠性.通過(guò)設(shè)置負(fù)載均衡集群將訪問(wèn)業(yè)務(wù)分?jǐn)偟絻膳_(tái)業(yè)務(wù)服務(wù)器上,降低了單個(gè)業(yè)務(wù)服務(wù)器的訪問(wèn)壓力.主從代理服務(wù)器的負(fù)載均衡是使用Nginx作為反向代理服務(wù)器來(lái)實(shí)現(xiàn)的.

圖1 系統(tǒng)架構(gòu)圖

分布式文件系統(tǒng) MongoDB GridFS部署在MongoDB分布式數(shù)據(jù)庫(kù)上.數(shù)據(jù)庫(kù)分成三個(gè)分片[4]進(jìn)行橫向擴(kuò)展.每個(gè)分片由3臺(tái)Mongod Server副本集組成以保證可靠性.

1.1 負(fù)載均衡集群架構(gòu)

系統(tǒng)使用2臺(tái)Nginx代理服務(wù)器作為系統(tǒng)的出口,通過(guò)一個(gè)虛擬IP對(duì)外提供服務(wù),如下圖2所示.為保證系統(tǒng)的高可用性,采用雙機(jī)熱備模式.兩臺(tái)代理服務(wù)器同一時(shí)間只有一臺(tái)在提供服務(wù).當(dāng)提供服務(wù)的一臺(tái)出現(xiàn)故障的時(shí)候,另外一臺(tái)會(huì)馬上自動(dòng)接管并且提供服務(wù),進(jìn)行無(wú)縫交接.雙機(jī)熱備是通過(guò)路由冗余協(xié)議在2臺(tái)代理服務(wù)器上分別安裝KeepAlive并進(jìn)行配置實(shí)現(xiàn)的.

1.2 MongoDB副本集

副本集架構(gòu)如下圖3所示,系統(tǒng)中一共包含4個(gè)副本集,每個(gè)副本集包含3個(gè)副本,分別是一個(gè)Primary,2個(gè)Secondary.3個(gè)副本在同步之后存儲(chǔ)的是同一份數(shù)據(jù).其中,主節(jié)點(diǎn)負(fù)責(zé)整個(gè)副本集的數(shù)據(jù)寫(xiě)入,從節(jié)點(diǎn)定期從主節(jié)點(diǎn)通過(guò)Oplog同步數(shù)據(jù)備份,通過(guò)配置可從距離最近節(jié)點(diǎn)讀取數(shù)據(jù),實(shí)現(xiàn)讀寫(xiě)分離.副本集之間通過(guò)心跳維持聯(lián)系,一但主節(jié)點(diǎn)掛掉失去聯(lián)系,從節(jié)點(diǎn)就會(huì)選舉一個(gè)新的主節(jié)點(diǎn),選舉過(guò)程對(duì)客戶端是透明的.副本集提供了數(shù)據(jù)的冗余備份,并因在多個(gè)服務(wù)器上可讀取存儲(chǔ)的數(shù)據(jù)副本,提高了數(shù)據(jù)的可用性和故障容忍性.

圖3 副本集架構(gòu)圖

1.3 MongoDB分片架構(gòu)

為提高存儲(chǔ)空間,分擔(dān)請(qǐng)求負(fù)載,采用MongoDB集群的分片配置[5],如下圖4所示.整個(gè)分片集群不同服務(wù)器分別承擔(dān)以下不同角色:

①M(fèi)ongos Server,路由服務(wù)器,數(shù)據(jù)庫(kù)集群請(qǐng)求的入口,負(fù)責(zé)把對(duì)應(yīng)的數(shù)據(jù)請(qǐng)求請(qǐng)求轉(zhuǎn)發(fā)到對(duì)應(yīng)的分片服務(wù)器上.管理操作、讀寫(xiě)操作都通過(guò)mongos server來(lái)完成,以保證集群多個(gè)組件處于一致的狀態(tài).

②Config Server,配置服務(wù)器,存儲(chǔ)所有數(shù)據(jù)庫(kù)元信息的配置,即各個(gè)chunk與分片服務(wù)器的映射關(guān)系.如下圖所示,將配置服務(wù)器配置成一個(gè)副本集防止系統(tǒng)單點(diǎn)故障.

③Shard Server,分片服務(wù)器,存儲(chǔ)數(shù)據(jù)庫(kù)中具體的的數(shù)據(jù).其中,每一個(gè)分片服務(wù)器是一個(gè)副本集保證數(shù)據(jù)可用性.如下圖所示,集群有3個(gè)分片服務(wù)器,必要時(shí)還可進(jìn)行擴(kuò)展.

在分片服務(wù)器里,MongoDB會(huì)把數(shù)據(jù)根據(jù)片鍵分為chunks,如圖5所示.當(dāng)一個(gè)chunk的大小超過(guò)配置中的chunk size時(shí),MongoDB的后臺(tái)進(jìn)程會(huì)把這個(gè)chunk切分成更小的chunk.除此之外,MongDB的后臺(tái)進(jìn)程Balancer負(fù)責(zé)chunk的遷移,從而均衡各個(gè)分片服務(wù)器的負(fù)載.這些過(guò)程對(duì)客戶端都是透明的.

圖4 MongoDB分片架構(gòu)圖

圖5 MongoDB chunk分布圖

1.4 GridFS

GridFS[6]是MongoDB之上的分布式文件系統(tǒng),通過(guò)MongoDB的復(fù)制,分片等機(jī)制來(lái)存儲(chǔ)文件數(shù)據(jù)和文件元數(shù)據(jù)并進(jìn)行管理與分析.GridFS將二進(jìn)制數(shù)據(jù)大文件分成很多塊,每一塊作為一個(gè)單獨(dú)的文檔存儲(chǔ).

GridFS使用兩個(gè)文檔來(lái)存儲(chǔ)二進(jìn)制數(shù)據(jù)文件,一個(gè)用來(lái)存儲(chǔ)文件本身的塊,另外一個(gè)用來(lái)存儲(chǔ)分塊的信息和文件的元數(shù)據(jù),默認(rèn)對(duì)應(yīng)的集合分別為fs.chunks和fs.files,其結(jié)構(gòu)如圖6所示.

fs.files這個(gè)集合Collection存儲(chǔ)文件元數(shù)據(jù),一般比較小,不需要分片存儲(chǔ).fs.chunks這個(gè)集合Collection存儲(chǔ)了文件數(shù)據(jù),比較大,根據(jù)files_id,n作為片鍵將不同chunk通過(guò)哈希分布到不同分片服務(wù)器上.

圖6 GridFS文件存儲(chǔ)

2 系統(tǒng)實(shí)現(xiàn)

2.1 運(yùn)行環(huán)境

運(yùn)行環(huán)境集群中有7臺(tái)服務(wù)器,其環(huán)境如表2所示,其中每臺(tái)服務(wù)器的配置環(huán)境如表1所示.

表1 服務(wù)器配置信息

2.2 配置

2.2.1 MongoDB和GridFS配置

MongoDB的配置[7]示意圖如下圖所示.在如下的配置中,任何一臺(tái)機(jī)器因故障不能提供服務(wù),都能保證MongoDB繼續(xù)提供正常的服務(wù),數(shù)據(jù)不丟失,保證容災(zāi)性.并且在相應(yīng)的配置后,能增加和減少節(jié)點(diǎn),有良好的可擴(kuò)展性.

在四個(gè)服務(wù)器上開(kāi)啟Mongod服務(wù),然后對(duì)Shard1、Shard2、Shard3和configReplSet副本集用mongo命令進(jìn)行連接,然后在Mongo Shell中配置副本集信息,如下所示.

表2 服務(wù)器集群環(huán)境

添加分片用命令mongo進(jìn)行連接mongos服務(wù)器端口,然后在MongoShell中配置分片信息,如下所示.

在新建數(shù)據(jù)庫(kù)test之后,對(duì)數(shù)據(jù)庫(kù)test開(kāi)啟分片. GridFS默認(rèn)使用兩種集合 Collection:fs.files和fs.chunks來(lái)存儲(chǔ)數(shù)據(jù),對(duì)集合fs.chunks開(kāi)啟分片和索引.在Mongo Shell中的配置如下所示:

2.2.2 Tomcat和Mysql安裝配置

Tomcat業(yè)務(wù)服務(wù)器集群結(jié)構(gòu)如圖7所示.

圖7 Tomcat服務(wù)器集群結(jié)構(gòu)

表3 Mongo服務(wù)器配置

在服務(wù)器 06、07,也就是 10.10.1.139和10.10.1.144上下載并安裝Tomcat 8.并將Java Web應(yīng)用打包成 war包,然后發(fā)布到 Tomcat服務(wù)器的webapps目錄下.并在服務(wù)器06上安裝和啟動(dòng)Mysql. Web應(yīng)用使用其作為數(shù)據(jù)庫(kù)服務(wù)器.

2.2.3 Nginx、Memcached和Keepalived配置安裝

在服務(wù)器07上用git下載nginx-gridfs插件,并安裝和編譯,命令如下所示:

在nginx配置文件中配置負(fù)載均衡業(yè)務(wù)服務(wù)器與MongoDB Mongos IP地址與端口,如下所示.

Mencached是一個(gè)高性能的分布式的內(nèi)存對(duì)象緩存系統(tǒng),負(fù)責(zé)業(yè)務(wù)服務(wù)器間共享session對(duì)象信息,在服務(wù)器07上安裝和啟動(dòng).然后在服務(wù)器06和07的Tomcat里配置支持Mencached的session管理,即修改文件server.xml,添加Mencached服務(wù)器配置信息.

在服務(wù)器05和服務(wù)器06上,下載安裝Keepalived,并對(duì)Keepalived的配置文件keepalived.conf進(jìn)行配置,在其中設(shè)置服務(wù)器05是主服務(wù)器,而06是備服務(wù)器.然后,在這2臺(tái)服務(wù)器上啟用Keepalived服務(wù).為了使主服務(wù)器Keepalived正常運(yùn)行而Nginx出現(xiàn)故障時(shí),關(guān)閉服務(wù),能夠順利切換,創(chuàng)建監(jiān)控腳本,并在Keepalived配置文件中實(shí)現(xiàn)監(jiān)控.

3 系統(tǒng)測(cè)試

3.1 響應(yīng)性能測(cè)試

對(duì)部署在系統(tǒng)中Web應(yīng)用的響應(yīng)性能用Jmeter進(jìn)行測(cè)試,其中采用的Web測(cè)試應(yīng)用的后臺(tái)技術(shù)架構(gòu)是SpringMVC3.對(duì)部署在單個(gè)服務(wù)器上的同一Web應(yīng)用響應(yīng)性能對(duì)比.分別模擬30,50,80,100,120個(gè)用戶在1秒內(nèi)發(fā)出HTTP請(qǐng)求以測(cè)試其并發(fā)性能,測(cè)量值分別如下表3所示.其中,Samples表示一共完成了多少個(gè)線程,Average表示平均響應(yīng)時(shí)間,單位是毫秒, Median表示統(tǒng)計(jì)意義上面的響應(yīng)時(shí)間的中值,單位是毫秒,99%Line表示所有線程中99%的線程的響應(yīng)時(shí)間都小于或大于當(dāng)前數(shù)值,單位是毫秒,Min表示最小響應(yīng)時(shí)間,單位是毫秒,Max表示最大響應(yīng)時(shí)間,單位是毫秒.

可看到,隨著并發(fā)訪問(wèn)數(shù)的提高,優(yōu)化后的系統(tǒng)的響應(yīng)時(shí)間越少,吞吐量越大.然而,并發(fā)訪問(wèn)數(shù)提高,漸漸超過(guò)系統(tǒng)的承受能力,錯(cuò)誤率也開(kāi)始提高.在并發(fā)訪問(wèn)為80及80以下時(shí),單服務(wù)器響應(yīng)性能均比優(yōu)化后的系統(tǒng)表現(xiàn)要好,這可能是因?yàn)檫€沒(méi)達(dá)到單服務(wù)器并發(fā)性能極限,而且,通過(guò)Nginx請(qǐng)求轉(zhuǎn)發(fā)還需要相應(yīng)的時(shí)間消耗.在并發(fā)訪問(wèn)為80左右時(shí),平均響應(yīng)時(shí)間縮短9%,其趨勢(shì)如下圖8所示.這可能是因?yàn)?隨著并發(fā)訪問(wèn)數(shù)的提高,單服務(wù)器響應(yīng)性能逐漸降低,而通過(guò)Nginx的分發(fā)和兩臺(tái)服務(wù)器分擔(dān)請(qǐng)求,單個(gè)服務(wù)器所需承擔(dān)的并發(fā)數(shù)下降,其服務(wù)器響應(yīng)性能也維持在較高的狀態(tài).而在并發(fā)訪問(wèn)數(shù)達(dá)到100時(shí),單服務(wù)器開(kāi)始出錯(cuò),說(shuō)明已經(jīng)達(dá)到它的并發(fā)極限.而優(yōu)化后的系統(tǒng)運(yùn)行良好.直到并發(fā)訪問(wèn)數(shù)達(dá)到120,才達(dá)到優(yōu)化后的系統(tǒng)的并發(fā)極限.

表4 并發(fā)訪問(wèn)數(shù)據(jù)對(duì)比

圖7 平均響應(yīng)時(shí)間增長(zhǎng)趨勢(shì)圖

3.2 GridFS文件并發(fā)讀寫(xiě)性能

3.2.1 GridFS文件并發(fā)寫(xiě)性能

通過(guò)GridFS Java驅(qū)動(dòng),編寫(xiě)Java測(cè)試應(yīng)用程序,在其中創(chuàng)建并發(fā)訪問(wèn)線程進(jìn)行測(cè)試,模擬并發(fā)訪問(wèn)十次的平均值,以減少誤差.然后與Linux EXT4文件系統(tǒng)在500K和20M大小的文件寫(xiě)文件效率進(jìn)行對(duì)比,并記錄其響應(yīng)時(shí)間,如下圖所示.其中文件都是保存在同一個(gè)目錄下.可以看出,無(wú)論是在大文件還是小文件, GridFS文件上傳時(shí)間雖然比EXT4要慢.但是,隨著并發(fā)數(shù)的上升,文件上傳的最大時(shí)間是比較穩(wěn)定的.

上傳時(shí)間較慢原因有以下幾個(gè):第一,在寫(xiě)文件時(shí),觀察GridFS數(shù)據(jù)庫(kù)分片狀態(tài)的變化,發(fā)現(xiàn)文件寫(xiě)入總是在同一個(gè)節(jié)點(diǎn)上.這是因?yàn)榧蟜s.chunks的分片片鍵是(files_id,n),而其中files_id是自動(dòng)生成的.在這種情況下,插入總是在一個(gè)分片上操作.第二,由于Balancer的Chunks均衡時(shí)要鎖定資源,速度較慢,來(lái)不及將新插入的Chunks遷移.第三,在集合fs.files和fs.chunks上建立了索引,對(duì)插入速度也有影響.第四,其他因素的影響可能導(dǎo)致結(jié)果有誤差,如CPU資源,緩存資源的占用等.

3.2.2 GridFS文件并發(fā)讀性能

通過(guò)MongoDB GridFS的JavaAPI測(cè)試文件的下載效率.GridFS下載測(cè)試是通過(guò)Nginx GridFS模塊在Nginx上下載,而對(duì)比的是通過(guò)TomcatWeb服務(wù)器在EXT4本地文件系統(tǒng)上下載,在這里搭建了NFS文件共享系統(tǒng)方便進(jìn)行對(duì)比.500K和500M空間大小的文件下載時(shí)間如下圖8所示,其中文件都是保存在同一個(gè)目錄下.

圖8 500K和20M文件并發(fā)上傳時(shí)間

GridFS的并發(fā)查詢優(yōu)勢(shì)在于通過(guò)Balancer的策略將數(shù)據(jù)塊chunks的查詢均勻的分布在各個(gè)分片上,訪問(wèn)負(fù)載也隨著分散到各個(gè)分片上,從而提高并發(fā)性能.事實(shí)上,當(dāng)存儲(chǔ)的文件數(shù)據(jù)量少,由于路由查詢等消耗,GridFS的優(yōu)勢(shì)并不明顯.除此之外,相對(duì)于Linux EXT4文件系統(tǒng)的單個(gè)目錄下能存放的文件和文件夾數(shù)目有限而且過(guò)多的文件數(shù)目會(huì)導(dǎo)致文件搜索時(shí)間過(guò)長(zhǎng)的問(wèn)題而言,GridFS將文件名和路徑信息存放在fs.files里面則沒(méi)有這些問(wèn)題.

文件下載速度與當(dāng)前網(wǎng)絡(luò)帶寬關(guān)系密切,而網(wǎng)絡(luò)帶寬是隨著時(shí)間動(dòng)態(tài)變化的.測(cè)試雖然采取多次測(cè)量取平均值,仍然可能導(dǎo)致數(shù)據(jù)測(cè)量有一定偏差.

4 總結(jié)

針對(duì)不斷提高的文件存儲(chǔ)需求以及高流量高并發(fā)的Web應(yīng)用訪問(wèn)有延遲的問(wèn)題,本文提出了一種Web優(yōu)化策略對(duì)網(wǎng)站響應(yīng)性能、文件存儲(chǔ)容量、可用性、可靠性和并發(fā)讀取性能等方面進(jìn)行提升.對(duì)這種優(yōu)化的部署架構(gòu)的響應(yīng)性能和文件下載速率做了實(shí)驗(yàn)和測(cè)試發(fā)現(xiàn),通過(guò)Nginx系統(tǒng)在高并發(fā)情況下有9%的性能提升.而且MongoDB Gridfs集群的文件上傳速率穩(wěn)定,下載速率在文件較大的情況下性能較好.

1 Chodorow K.MongoDB:The Definitive Guide.O’Reilly Media,Inc.2013.

2 Fitzpatrick B.Distributed caching with memcached.Linux Journal,2004,(124):72–76.

3 Chi X,Liu B,Niu Q,et al.Web load balance and cache optimization design based nginx under high-concurrency environment.2012 Third International Conference on Digital Manufacturing and Automation(ICDMA).IEEE.2012. 1029–1032.

4 Liu Y,Wang Y,Jin Y.Research on the improvement of MongoDB auto-sharding in cloud environment.2012 7th International Conference on Computer Science&Education (ICCSE).IEEE.2012.851–854.

5 Jiang W,Zhang L,Liao X,et al.A novel clustered MongoDB-based storage system for unstructured data with high availability.Computing,2014,96(6):455–478.

6 Gu Y,Wang X,Shen S,et al.Analysis of data storage mechanism in NoSQL database MongoDB.2015 IEEE International Conference on Consumer Electronics-Taiwan (ICCE-TW).IEEE.2015.70–71.

7劉一夢(mèng).基于MongoDB的云數(shù)據(jù)管理技術(shù)的研究與應(yīng)用[碩士學(xué)位論文].北京:北京交通大學(xué),2012.

Optimisation Strategy for WebApplications Based on MongoDB

LU Zhi-Tong,LI Zhong,KE Yong,SUN Jian-Ying

(Computer Network Information Center,ChineseAcademy of Sciences,Beijing 100190,China)

With the growing demand for massive file storage and high number of concurrent accesses to enhance performance of the system.In this paper,we propose an optimization strategy of web applications,which can expand the storage capacity,availability and reliability with MongoDB GridFS,and also can support load balancing and hot standby with Nginx and Keepalived,optimizing concurrent performance.We test the concurrent performances of the web application and the experimental results show that the average response time could be reduce by 9%when the number of concurrent accesses increases to more than 80.When files are uploaded concurrently through Nginx Gridfs,the performance is stable.The file-download speeds of larger files are faster than those through local file system EXT4.

MongoDB;GridFS;Nginx;Keepalived;concurrency

2016-09-05;收到修改稿時(shí)間:2016-10-17

10.15888/j.cnki.csa.005767