摘 要: 為適應(yīng)集群環(huán)境下數(shù)據(jù)量在100GB以下數(shù)據(jù)庫訪問頻繁和響應(yīng)速度較高的需要,提出一種架構(gòu)于Linux虛擬服務(wù)器(LVS)基礎(chǔ)之上、應(yīng)用廣泛且擴(kuò)展性強(qiáng)的數(shù)據(jù)庫集群服務(wù)器結(jié)構(gòu),并在復(fù)制技術(shù)的基礎(chǔ)上進(jìn)行改進(jìn),改變復(fù)制對(duì)象,給出了相應(yīng)特定的復(fù)制算法,并且通過實(shí)驗(yàn)驗(yàn)證了系統(tǒng)的可行性。
關(guān)鍵詞: 復(fù)制 負(fù)載平衡 集群 數(shù)據(jù)庫
隨著Internet業(yè)務(wù)量爆炸性的增長,使得傳統(tǒng)的單一數(shù)據(jù)庫服務(wù)器不堪重負(fù)。不斷更新的硬件只會(huì)使整個(gè)系統(tǒng)的代價(jià)升高且收效甚微,并且還會(huì)造成資源的浪費(fèi)。由此,基于集群的網(wǎng)絡(luò)負(fù)載平衡策略應(yīng)運(yùn)而生并成為有效的新對(duì)策。
本文提出了一種構(gòu)架于Linux虛擬服務(wù)器(LVS)基礎(chǔ)之上的數(shù)據(jù)庫集群服務(wù)器體系結(jié)構(gòu),用于解決數(shù)據(jù)量在100G以下且數(shù)據(jù)庫訪問頻繁和對(duì)響應(yīng)速度要求較高的需求。重點(diǎn)提出了與這種體系結(jié)構(gòu)相對(duì)應(yīng)的基于SQL語句分發(fā)請(qǐng)求的復(fù)制算法,并通過實(shí)驗(yàn)來驗(yàn)證算法的可行性。由于所采用的設(shè)備均是普通的PC機(jī)和交換機(jī),所使用的系統(tǒng)平臺(tái)是源碼開放的Linux操作系統(tǒng),并且系統(tǒng)是針對(duì)Anycast型[2]任務(wù)開發(fā)的,可以應(yīng)用于絕大多數(shù)的網(wǎng)站和論壇,所以具有一定的推廣價(jià)值。
1 數(shù)據(jù)復(fù)制技術(shù)
通常,服務(wù)器的數(shù)據(jù)分為兩種:一種是結(jié)構(gòu)化的數(shù)據(jù)庫數(shù)據(jù),另一種是非結(jié)構(gòu)化或半結(jié)構(gòu)化的文件[4]。這里只討論結(jié)構(gòu)化的數(shù)據(jù)庫數(shù)據(jù)。
數(shù)據(jù)庫集群的數(shù)據(jù)復(fù)制包括數(shù)據(jù)定位和數(shù)據(jù)更新。對(duì)于數(shù)據(jù)定位,目前有三種方式:
(1)采用分區(qū)方式,即對(duì)數(shù)據(jù)庫中的數(shù)據(jù)進(jìn)行劃分操作,其保證了數(shù)據(jù)操作的高效率,但不能保證數(shù)據(jù)的高可用性和高可靠性" title="高可靠性">高可靠性。
(2)采用不分區(qū)方式,使得數(shù)據(jù)庫在每個(gè)節(jié)點(diǎn)上都保存有副本,其保證了數(shù)據(jù)的高可用性和高可靠性,但數(shù)據(jù)同步困難。本文則是由此切入,提出一種新算法用以解決在保證數(shù)據(jù)的高可用性和高可靠性的情況下數(shù)據(jù)同步困難的問題。
(3)上述兩者相結(jié)合,這樣就需要?jiǎng)討B(tài)的數(shù)據(jù)分配策略來管理這些數(shù)據(jù),當(dāng)然也可以通過手動(dòng)管理方式來模擬此過程。
數(shù)據(jù)更新一般使用即時(shí)更新。
對(duì)于采取不分區(qū)方式的數(shù)據(jù)定位,其數(shù)據(jù)更新常用的算法有快照復(fù)制、基于主節(jié)點(diǎn)的對(duì)稱復(fù)制、基于TOKEN的對(duì)稱復(fù)制和混合復(fù)制。這些算法都各有千秋,但它們有一個(gè)共同的特點(diǎn),即都是在節(jié)點(diǎn)之間或主節(jié)點(diǎn)與從節(jié)點(diǎn)之間拷貝數(shù)據(jù)。人們知道,任何情況下,對(duì)數(shù)據(jù)庫的操作無非只有四種:增、刪、改、查。對(duì)于這種基于負(fù)載調(diào)度請(qǐng)求的且不能識(shí)別請(qǐng)求內(nèi)容而只把數(shù)據(jù)庫當(dāng)作文件來操作的算法,不但不能發(fā)揮數(shù)據(jù)庫存取數(shù)據(jù)的優(yōu)勢(shì),同時(shí)也為整個(gè)集群帶來了額外的開銷,所以不能說是真正意義上的數(shù)據(jù)庫集群。
2 系統(tǒng)設(shè)計(jì)
為了保證數(shù)據(jù)的高可用性和高可靠性,同時(shí)又能提高數(shù)據(jù)更新的效率,充分發(fā)揮數(shù)據(jù)庫本身的優(yōu)勢(shì),本文提出一種新的思路,即在LVS基礎(chǔ)之上,將其內(nèi)網(wǎng)中傳送的數(shù)據(jù)包變成SQL語句,通過數(shù)據(jù)接口,在各個(gè)節(jié)點(diǎn)機(jī)上對(duì)其各自擁有數(shù)據(jù)庫進(jìn)行讀寫操作。由于所傳送的對(duì)象不是整塊數(shù)據(jù)而是一條條的SQL語句,使得整個(gè)集群減少了更新時(shí)間并且增強(qiáng)了負(fù)載能力。
如圖1所示,本系統(tǒng)是基于LVS的直接路由模式(DR)來構(gòu)建的。其采用單工連接方式,節(jié)點(diǎn)服務(wù)器處理過的應(yīng)答數(shù)據(jù)不再經(jīng)過均衡器" title="均衡器">均衡器,而直接返回給客戶端" title="客戶端">客戶端,這就是說,每個(gè)節(jié)點(diǎn)服務(wù)器都擁有能夠到達(dá)客戶端的合法IP地址,并且負(fù)載均衡器" title="負(fù)載均衡器">負(fù)載均衡器與各節(jié)點(diǎn)服務(wù)器必須有一塊網(wǎng)卡與內(nèi)網(wǎng)交換機(jī)相連。同時(shí),為了使節(jié)點(diǎn)間負(fù)載平衡、節(jié)點(diǎn)內(nèi)有序執(zhí)行,在每個(gè)節(jié)點(diǎn)服務(wù)器上都設(shè)置有一個(gè)隊(duì)列結(jié)構(gòu),用于保證操作的順序性,并且在負(fù)載均衡器上設(shè)置有兩個(gè)對(duì)列結(jié)構(gòu)用于協(xié)調(diào)節(jié)點(diǎn)間查詢和更新的操作。
3 基于SQL語句分發(fā)請(qǐng)求的復(fù)制算法
復(fù)制算法一般包括數(shù)據(jù)的定位和數(shù)據(jù)副本的同步兩部分,本算法也是如此。
3.1 數(shù)據(jù)的定位
如上所述,基于本算法的系統(tǒng)結(jié)構(gòu)中所使用的定位技術(shù)是基于定位服務(wù)器的方式。也就是說,從客戶端發(fā)出的對(duì)數(shù)據(jù)庫操作的任何請(qǐng)求都必須經(jīng)過定位服務(wù)器的分發(fā)后,請(qǐng)求才能在節(jié)點(diǎn)服務(wù)器上得到響應(yīng)。本系統(tǒng)中,定位服務(wù)器就是負(fù)載均衡器。
如圖2所示,當(dāng)負(fù)載均衡器收到客戶端對(duì)數(shù)據(jù)庫操作的請(qǐng)求后,首先要進(jìn)行區(qū)分,即是SELECT語句還是非SELECT語句,當(dāng)請(qǐng)求是SELECT語句時(shí),則通過負(fù)載平衡算法[2]選擇當(dāng)前負(fù)載最輕的節(jié)點(diǎn),然后將SELECT語句發(fā)送到此節(jié)點(diǎn),在節(jié)點(diǎn)數(shù)據(jù)庫中進(jìn)行查詢處理后直接將應(yīng)答數(shù)據(jù)返回給客戶端,而此時(shí)的返回?cái)?shù)據(jù)包的源IP地址仍然是負(fù)載均衡器上的VIP地址(這是由LVS的直接路由模式?jīng)Q定的)。
可是,當(dāng)請(qǐng)求是非SELECT語句時(shí),情況則有所不同,因?yàn)樗蟹荢ELECT語句均是更新語句,如INSERT、DELECT和UPDATE。此時(shí),負(fù)載均衡器通過其所擁有的鄰接表查找各節(jié)點(diǎn)的MAC地址,然后復(fù)制與節(jié)點(diǎn)數(shù)量相同請(qǐng)求包,再分別封裝成幀并改寫幀上的MAC地址,使每個(gè)節(jié)點(diǎn)都成為目的節(jié)點(diǎn),接著將這批幀發(fā)送到內(nèi)網(wǎng)。于是,每個(gè)節(jié)點(diǎn)服務(wù)器都將收到符合自己MAC地址的幀后,拆裝、提取SQL信息,在節(jié)點(diǎn)數(shù)據(jù)庫中進(jìn)行數(shù)據(jù)更新,最后再將更新后的狀態(tài)信息(如更新成功或失敗)直接返回給客戶端,同樣此時(shí)的返回包的源IP地址仍然是均衡器上的VIP。
3.2 數(shù)據(jù)副本的同步
本系統(tǒng)在進(jìn)行數(shù)據(jù)同步時(shí),采用即時(shí)更新的同步技術(shù)。
由于數(shù)據(jù)庫集群服務(wù)器的數(shù)據(jù)庫都是相對(duì)獨(dú)立的,每臺(tái)服務(wù)器都可以獨(dú)立承擔(dān)服務(wù)工作,且數(shù)據(jù)的復(fù)制度較高,不存在單點(diǎn)失效的問題,所以節(jié)點(diǎn)服務(wù)器的工作重點(diǎn)應(yīng)是數(shù)據(jù)快速而穩(wěn)定的存取,保持各節(jié)點(diǎn)間數(shù)據(jù)的一致性。因此,當(dāng)有請(qǐng)求到達(dá)時(shí),無論是查詢語句(SELECT語句)還是更新語句(非SELECT語句),都先進(jìn)入節(jié)點(diǎn)機(jī)上的操作隊(duì)列,如圖3所示,然后逐一順序取出執(zhí)行,這樣可以保證對(duì)數(shù)據(jù)庫操作的順序性和一致性。
3.3 復(fù)制算法的實(shí)現(xiàn)
(1)負(fù)載均衡器上鄰接狀態(tài)表,請(qǐng)求隊(duì)列和更新隊(duì)列
可以看出,負(fù)載均衡器是這個(gè)集群系統(tǒng)" title="集群系統(tǒng)">集群系統(tǒng)的核心。均衡器是通過鄰接狀態(tài)表來管理集群中節(jié)點(diǎn)服務(wù)器的。鄰接狀態(tài)表是由節(jié)點(diǎn)名、MAC地址和狀態(tài)構(gòu)成。節(jié)點(diǎn)名是管理員預(yù)先定義的,用于區(qū)分各節(jié)點(diǎn)機(jī); MAC地址是指節(jié)點(diǎn)服務(wù)器對(duì)應(yīng)于內(nèi)網(wǎng)的那塊網(wǎng)卡的地址;狀態(tài)是指當(dāng)前節(jié)點(diǎn)機(jī)的狀態(tài)(0為可操作,1為忙,2為停機(jī))。當(dāng)有請(qǐng)求到達(dá)時(shí),均衡器首先區(qū)分請(qǐng)求中的是SELECT語句還是非SELECT語句,若是SELECT語句,則從鄰接狀態(tài)表中查找狀態(tài)為0的節(jié)點(diǎn),若為0的節(jié)點(diǎn)多于一個(gè)時(shí),則通過負(fù)載平衡算法[2]選出負(fù)載最輕的節(jié)點(diǎn)進(jìn)行分配;若是非SELECT語句,均衡器便查找狀態(tài)不為2(即停機(jī))的節(jié)點(diǎn)分發(fā)請(qǐng)求,若其中有節(jié)點(diǎn)的狀態(tài)為1(即忙,也就是說此節(jié)點(diǎn)服務(wù)器上的操作隊(duì)列已滿),則將該語句入均衡器上的更新隊(duì)列排隊(duì),直到所有運(yùn)行節(jié)點(diǎn)均為不忙,才出隊(duì)分發(fā);若所有運(yùn)行節(jié)點(diǎn)的狀態(tài)均不為0,此時(shí)若帶有SELECT語句的請(qǐng)求到達(dá),均衡器便將該語句入請(qǐng)求隊(duì)列,直到有狀態(tài)為0的節(jié)點(diǎn)出現(xiàn),才出隊(duì)進(jìn)行分發(fā);當(dāng)均衡器上的請(qǐng)求隊(duì)列或更新隊(duì)列均滿時(shí),均衡器將拒絕查詢請(qǐng)求或更新請(qǐng)求,直到隊(duì)列不滿。
圖2中,Qempty(Q)、Qinsert(Q,i)、Qdelete(Q)和Qlength(Q)是對(duì)隊(duì)列的判空、入隊(duì)、出隊(duì)和求長度的操作,get_load_request()為取請(qǐng)求函數(shù),send_load_request()為發(fā)送請(qǐng)求函數(shù)。
(2)節(jié)點(diǎn)服務(wù)器上的操作隊(duì)列和信號(hào)機(jī)制
節(jié)點(diǎn)服務(wù)器的主要工作是對(duì)數(shù)據(jù)庫的存取。引入操作隊(duì)列就是為了保證對(duì)數(shù)據(jù)庫操作的順序性和一致性。這里,需要再引入兩個(gè)信號(hào)量DOWN和FULL,用以監(jiān)控節(jié)點(diǎn)機(jī)的狀態(tài)。DOWN為節(jié)點(diǎn)機(jī)系統(tǒng)狀態(tài)(0為正常,1為異常),F(xiàn)ULL為操作隊(duì)列狀態(tài)(0為隊(duì)列滿,1為隊(duì)列不滿),它們分別與負(fù)載均衡器上狀態(tài)值同步,其對(duì)照表如表1所示。
圖3中,Qempty(Q)、Qdelete(Q)和Qinsert(Q,q)是對(duì)隊(duì)列的判空、出隊(duì)和入隊(duì)的操作,get_lvs_request()為取請(qǐng)求函數(shù),Exesql(q,local)為SQL執(zhí)行函數(shù)。
4 系統(tǒng)實(shí)現(xiàn)與測(cè)試
4.1 系統(tǒng)實(shí)現(xiàn)
本集群系統(tǒng)性能測(cè)試環(huán)境如下:
(1)基于6+1臺(tái)PC的集群服務(wù)器,即一臺(tái)作負(fù)載均衡器,剩余6臺(tái)作節(jié)點(diǎn)服務(wù)器。PC機(jī)的基本配置為:CPU PⅢ 900MHz,內(nèi)存為384MB,硬盤為40GB。
(2)交換機(jī)為24Port 10/100Mbps Fast ethernet Switch。
(3)軟件配置:
操作系統(tǒng):Linux 7.2 內(nèi)核為2.4.18。
集群中間件(SSI):使用JAVA開發(fā)的基于SQL語句復(fù)制的數(shù)據(jù)庫集群算法。
數(shù)據(jù)庫為:MySql 3.23.49。
網(wǎng)絡(luò)協(xié)議:TCP/IP。
(4)測(cè)試軟件:WebBench。
4.2 測(cè)試與分析
為使測(cè)試更具對(duì)比性,選用兩種算法進(jìn)行,一種是基于SQL語句復(fù)制的算法,另一種是基于快照復(fù)制[3]的算法。
(1)測(cè)試基于數(shù)據(jù)庫服務(wù)器集群系統(tǒng)的查詢請(qǐng)求的吞吐量。
(2)測(cè)試基于數(shù)據(jù)庫服務(wù)器集群系統(tǒng)的更新請(qǐng)求的吞吐量。
從以上結(jié)果可以看出,在測(cè)試查詢請(qǐng)求的情況下,雖然基于SQL語句復(fù)制的算法略高些,但兩者相差不是很大,如圖4所示。在測(cè)試更新請(qǐng)求的情況下,差距很明顯,如圖5所示,由于基于快照復(fù)制算法的系統(tǒng),所有的更新都在一臺(tái)主節(jié)點(diǎn)上進(jìn)行,然后再將更新數(shù)據(jù)分發(fā)到其他備份節(jié)點(diǎn)。這樣,雖然能夠保證數(shù)據(jù)的一致性,但主節(jié)點(diǎn)很容易形成新的瓶頸,使得在節(jié)點(diǎn)增多的情況下,主節(jié)點(diǎn)負(fù)載過大。然而,基于SQL語句復(fù)制算法的系統(tǒng),由于所傳送的為一條一條的語句,并非整塊數(shù)據(jù),所以在節(jié)點(diǎn)服務(wù)器上對(duì)其處理的速度就比較快,并且內(nèi)部的網(wǎng)絡(luò)傳輸影響甚小,從而使集群整體的更新速度得到提高。
本文提出了一種新的基于SQL語句請(qǐng)求分發(fā)的數(shù)據(jù)庫集群服務(wù)器的體系結(jié)構(gòu),對(duì)于研究和開發(fā)數(shù)據(jù)庫集群服務(wù)器,特別是集群環(huán)境中的數(shù)據(jù)同步管理,具有一定的指導(dǎo)意義和參考價(jià)值。
目前系統(tǒng)處于測(cè)試階段,還需要不斷完善。例如在網(wǎng)絡(luò)協(xié)議方面,TCP/IP協(xié)議雖然是一種很好的協(xié)議,但在相對(duì)距離較近、且同構(gòu)的集群系統(tǒng)中,其網(wǎng)絡(luò)開銷自然不容輕視;還有,由于本集群采用的是集中式分配器作為整個(gè)上行數(shù)據(jù)的入口點(diǎn),所有的負(fù)載分配工作都集中在負(fù)載均衡器上,當(dāng)負(fù)載均衡器出現(xiàn)故障或負(fù)載過重時(shí),將直接影響到整個(gè)集群系統(tǒng)的性能;另外,系統(tǒng)的容錯(cuò)性和安全性等問題都需要進(jìn)一步解決。
參考文獻(xiàn)
1 Zegura E W,Ammar M H,F(xiàn)ei Zongming et al.Application-Layer Anycasting:A Server Selection Architecture and Use in a Replicated Web Service.IEEE/ACM Transactions on Net-working,2000;8(4)455-466
2 Hui L,Qinke P,Junyi S.Node-Agents Based Clustered Database Server.Mini-Micro Systems,2003;24(2)225-229
3 邵佩英.分布式數(shù)據(jù)庫系統(tǒng)及其應(yīng)用.北京:科學(xué)出版社,2005
4 Content manage 8.1,IBM.http://www-900.ibm.com/cn/soft-ware/products/db2/index_solution.shtml
5 Shah S.Linux管理員指南.北京:機(jī)械工業(yè)出版社,2001
6 毛德操,胡希明.Linux內(nèi)核源代碼情景分析.杭州:浙江大學(xué)出版社,2001