一種高性能分布式數(shù)據(jù)緩存系統(tǒng)設(shè)計(jì)劉清（南京高等職業(yè)技術(shù)學(xué)校，南京210046）摘要：針對(duì)大規(guī)模實(shí)時(shí)性處理的需要，提高海量數(shù)據(jù)處理的效率，本文提出了一種高性能的分布式緩存服務(wù)系統(tǒng)模型。該系統(tǒng)選用epoll模型來解決系統(tǒng)的并發(fā)量瓶頸，使用優(yōu)秀的memcached服務(wù)器來緩存用戶的熱點(diǎn)請(qǐng)求資源，同時(shí)結(jié)合優(yōu)化調(diào)整后的mysql磁盤數(shù)據(jù)庫來保障數(shù)據(jù)的冗余性。經(jīng)過測(cè)試后，性能提高顯著，可以為今后的高并發(fā)、分布式的數(shù)據(jù)服務(wù)系統(tǒng)的設(shè)計(jì)提供一個(gè)新的思路。關(guān)鍵詞：Epoll；Memcached；分布式；數(shù)據(jù)緩存TheDesignofAHigh-performanceDistributedDataCacheSystemLiuQing（CollegeofTelecommunication&InformationEngineering,NanjingUniversityofPostsand

Telecommunications,Nanjing210046,China）Abstract:Accordingtotheneedsoflarge-scalereal-timeprocessingandtheneedsofimprovingtheefficiencyofmassdataprocessing,thispaperputsforwardakindofhigh-performancedistributedcacheservicesystemmodel.Thissystemchoosestheepollmodeltosolvethesystemconcurrencyvaluebottleneck,usesexcellentMemcachedservertocachetheuser’shotrequests,andcombineswiththeoptimizedmysqldiskdatabasetoguaranteetheredundancyofthedata.Aftertesting,thissystemhasagoodperformance,anditcanprovideanewthoughtforthehighconcurrent,distributeddataservicesysteminthefuture.Keywords:Epoll;Memcached;Distributed;Datacache1引言隨著現(xiàn)代通信技術(shù)高速的發(fā)展，隨之出現(xiàn)的服務(wù)用戶量的迅速增加，直接導(dǎo)致運(yùn)營(yíng)商所要處理的數(shù)據(jù)呈現(xiàn)海量的增長(zhǎng)，這些都對(duì)當(dāng)前電信運(yùn)營(yíng)商的業(yè)務(wù)支撐系統(tǒng)提出了新的要求，也對(duì)運(yùn)營(yíng)支撐系統(tǒng)的穩(wěn)定性、準(zhǔn)確性和實(shí)時(shí)性提出了更嚴(yán)峻的挑戰(zhàn)。傳統(tǒng)的電信業(yè)務(wù)數(shù)據(jù)的處理采取的是一般的磁盤數(shù)據(jù)庫，基于文件系統(tǒng)的特性使性能提升受到了很大的限制，但是隨著業(yè)務(wù)處理模式日趨復(fù)雜，電信業(yè)用戶數(shù)的增長(zhǎng)，傳統(tǒng)的方式必然會(huì)導(dǎo)致系統(tǒng)CPU和I/O占用不斷成線性增加，在此情況下，即使增加硬件支持，在現(xiàn)有框架下系統(tǒng)的處理速度也很難得到質(zhì)的提高。在這樣的背景下，對(duì)于高性能分布式數(shù)據(jù)緩存技術(shù)的研究，成為電信運(yùn)營(yíng)商和電子商務(wù)平臺(tái)，包括其它業(yè)務(wù)高速增長(zhǎng)的企業(yè)都亟待面臨解決的問題和挑戰(zhàn)。其高并發(fā)性、低延遲和高效性的要求，對(duì)系統(tǒng)的架構(gòu)設(shè)計(jì)、性能指標(biāo)等各方面都提出了新的挑戰(zhàn)【1】。文章將結(jié)合以上要求，提出一種分布式數(shù)據(jù)緩存技術(shù)的系統(tǒng)模型NuptCache，在Linux平臺(tái)下使用C語言設(shè)計(jì)開發(fā)并進(jìn)行性能測(cè)試，驗(yàn)證此模型能夠達(dá)到設(shè)定的要求，能夠更快更穩(wěn)定地處理用戶的請(qǐng)求，保證系統(tǒng)服務(wù)的連續(xù)性。2系統(tǒng)模型框架NuptCache系統(tǒng)的設(shè)計(jì)目標(biāo)是針對(duì)大規(guī)模實(shí)時(shí)性處理的需要，提高海量數(shù)據(jù)處理的效率和加入分布式內(nèi)存緩存技術(shù)來實(shí)現(xiàn)對(duì)數(shù)據(jù)處理的低時(shí)延處理。選擇epoll模型【2】【3】來增強(qiáng)NuptCache系統(tǒng)的并發(fā)量；使用memcached緩存技術(shù)【4】【5】與mysql磁盤數(shù)據(jù)庫相結(jié)合，memcached服務(wù)器作為數(shù)據(jù)庫的前端，其中存放用戶經(jīng)常訪問的熱點(diǎn)資源，如存在，則將相應(yīng)的數(shù)據(jù)直接取出反饋給用戶，如果不存在，則查詢mysql數(shù)據(jù)庫，在結(jié)果返回給用戶的同時(shí)，同步到memcached緩存服務(wù)器。作者簡(jiǎn)介：劉清（1980?），南京高等職業(yè)技術(shù)學(xué)校教師，研究方向：無線通信與信號(hào)處理技術(shù)。

NuptCache分布式數(shù)據(jù)緩存系統(tǒng)共分為三層，分別為epoll接口層,memcached緩存層,mysql數(shù)據(jù)層。為了保證系統(tǒng)運(yùn)行的高效性，NuptCache沒有設(shè)置身份認(rèn)證機(jī)制，本文將NuptCache系統(tǒng)部署在內(nèi)網(wǎng)防火墻后面，確保通信的安全。用戶通過網(wǎng)絡(luò)與服務(wù)提供商系統(tǒng)的epoll接口層通信，調(diào)用緩存層數(shù)據(jù)，如沒有得到想要的信息則與數(shù)據(jù)層進(jìn)行通信，返回?cái)?shù)據(jù)的同時(shí)同步到緩存層。3系統(tǒng)內(nèi)部設(shè)計(jì)3.1Epoll接口層設(shè)計(jì)Epoll是Linux下多路復(fù)用IO接口select/poll的增強(qiáng)版本，它能顯著提高程序在大量并發(fā)連接中只有少量活躍的情況下的系統(tǒng)CPU利用率。相較于傳統(tǒng)的事件分派通告機(jī)制select/poll，Epoll只告之準(zhǔn)備就緒的socket文件描述符，當(dāng)我們調(diào)用epoll_wait()獲得準(zhǔn)備就緒的socket文件描述符時(shí)，返回的并不是實(shí)際的描述符，而是一個(gè)代表就緒描述符數(shù)量的值，只需去epoll指定的一個(gè)數(shù)組中，依次取得相應(yīng)數(shù)量的文件描述符，這里使用了內(nèi)存映射(memorymapping)技術(shù)，徹底省去了socket文件描述符在系統(tǒng)調(diào)用時(shí)復(fù)制的開銷。并且它采用了基于事件的就緒通知模式⑹，使得在相同硬件平臺(tái)上可以支持更多的網(wǎng)絡(luò)并發(fā)連接，并且滿足網(wǎng)絡(luò)應(yīng)用的實(shí)時(shí)通信需求。圖2epoll接口層的工作流程本系統(tǒng)使用epoll加多線程模型⑺⑻，能夠提高系統(tǒng)的響應(yīng)速度，讓網(wǎng)絡(luò)I/O和數(shù)據(jù)計(jì)算相互重疊，降低系統(tǒng)延遲。本系統(tǒng)使用單獨(dú)的線程來管理epoll模型的網(wǎng)絡(luò)I/O,當(dāng)系統(tǒng)接收到請(qǐng)求數(shù)據(jù)后，在開辟的已有線程池中查找空閑線程，并予以分配資源進(jìn)行數(shù)據(jù)處理，同時(shí)epoll模型繼續(xù)監(jiān)聽活動(dòng)網(wǎng)絡(luò)事件，與數(shù)據(jù)處理線程并行處理，當(dāng)系統(tǒng)處理信息完畢時(shí)，將數(shù)據(jù)反饋給用戶，同時(shí)釋放占有的線程資源。該模型能有效地劃分責(zé)任與功能，而不是把所有邏輯都塞到一個(gè)eventloop里，讓每個(gè)線程邏輯比較簡(jiǎn)單。intmain(intargc,char*argv){InitThreadPool();〃線程池初始化for(i=0;i<LISTEN_MAX;i++)//初始化服務(wù)監(jiān)聽{s_listens[i].port=10000+i;rc=InitListen(s_listens[i].ip,s_listens[i].port);〃創(chuàng)建監(jiān)聽}epfd=epoll_create(65535);〃設(shè)置集合for(i=0;i<LISTEN_MAX;i++){ev.events=EPOLLIN;//加入epoll事件集合if(epoll_ctl(epfd,EPOLL_CTL_ADD,s_listens[i].fd,&ev)<0)…}for(;;)//服務(wù)循環(huán){epoll_wait(epfd,events,LISTEN_MAX,-1);〃等待epoll事件for(i=0;i<nfds;i++)〃處理epoll事件{//接收客戶端連接sock_cli=accept(sock_listen,(structsockaddr*)&addr4,&addrlen);〃查詢空閑線程???}3.2緩存層和數(shù)據(jù)層設(shè)計(jì)對(duì)于緩存服務(wù)而言，命中率是至關(guān)重要的。命中率的提升可以通過采取有效的冗余策略來實(shí)現(xiàn)。memcached的設(shè)計(jì)本身不帶任何冗余機(jī)制，文中將其與mysql磁盤數(shù)據(jù)庫進(jìn)行了數(shù)據(jù)冗余機(jī)制圖3緩存層和數(shù)據(jù)層的工作流程圖memcached緩存層和mysql數(shù)據(jù)層的工作流程如圖3所示，將memcached和磁盤數(shù)據(jù)庫mysql的配合使用，memcached服務(wù)器作為NuptCache系統(tǒng)的緩存層，用戶首先通過指定的get操作訪問memcached服務(wù)器，如果存在相應(yīng)的數(shù)據(jù)則直接獲取出數(shù)據(jù)結(jié)果，查詢過程不需要查詢數(shù)據(jù)層的mysql數(shù)據(jù)庫；如果不存在，則查詢mysql數(shù)據(jù)庫，將結(jié)果返回給查詢者，并以key相應(yīng)的value值形式將查詢結(jié)果存儲(chǔ)在memcached服務(wù)器中。4NuptCache系統(tǒng)運(yùn)行效果及測(cè)試4.1系統(tǒng)測(cè)試環(huán)境硬件環(huán)境：本測(cè)試使用了兩臺(tái)主機(jī)作為NuptCache系統(tǒng)的服務(wù)器端，測(cè)試使用了一臺(tái)主機(jī)運(yùn)行mysql數(shù)據(jù)庫，一臺(tái)主機(jī)運(yùn)行epoll模型和3個(gè)memcached緩存。另外還使用了四臺(tái)主機(jī)運(yùn)行客戶端測(cè)試程序，每臺(tái)機(jī)器都模擬并發(fā)連接，向服務(wù)器端發(fā)送查詢請(qǐng)求。軟件環(huán)境：在安裝mysql和memcached軟件之前還需要將所要用到的庫文件進(jìn)行安裝，安裝的軟件包為mysql5.1.30、libevent、memcached、libmemcached-0.26；系統(tǒng)的運(yùn)行環(huán)境為suselinuxenterpriseserver。測(cè)試場(chǎng)景：我們?cè)趍ysql中創(chuàng)建表，存儲(chǔ)引擎選擇為InnoDB，表中存在兩列，第一個(gè)表列key屬性為char(40)，存放的是文件被用sha1哈希方式得出的40個(gè)字符，我們可以通過系統(tǒng)的隨機(jī)數(shù)函數(shù)生成1萬到100萬個(gè)不同的40個(gè)字符的key值來進(jìn)行測(cè)試，將此列作為唯一索引；第二個(gè)表列value屬性為varchar(800)，存放的是key值所匹對(duì)的數(shù)據(jù)，可以是圖片信息，或者是字符串信息，同樣可以使用隨機(jī)數(shù)函數(shù)模擬生成。4.2系統(tǒng)測(cè)試結(jié)果對(duì)高性能分布式數(shù)據(jù)緩存系統(tǒng)NuptCache的測(cè)試主要分為功能測(cè)試和性能測(cè)試。功能測(cè)試包括能夠處理大并發(fā)量的請(qǐng)求、能夠?qū)emcached緩存層已有的數(shù)據(jù)進(jìn)行查詢、對(duì)于在緩存層中未命中的數(shù)據(jù)進(jìn)行二次查詢并與緩存同步，并統(tǒng)計(jì)用戶查詢的命中率。linux-9：/Desktop/mcachs#memstat一-server^lO.W.9,￡Listing1ServerServer：(11211)pid：1875uptime:97time:1271589680version:L2.6poinTer_size:64rusage_iJser:0.140008rusage_system:0.300018curr,:1111bytes:909Curr^Corinectioni；5total_connections:10009cmd_get:10000cmjset:1geVhits：9999get_misses:1?圖4:NuptCache系統(tǒng)的命中率如圖4所示，可以從橙色區(qū)域看到，mcahce系統(tǒng)接收到10000次的數(shù)據(jù)請(qǐng)求查詢，在系統(tǒng)數(shù)據(jù)層響應(yīng)了一次，經(jīng)過同步后，將其映射到緩存層。在接下來的9999次查詢中，用戶每次都能從NuptCache系統(tǒng)的緩存層得到響應(yīng)，從而驗(yàn)證了NuptCache系統(tǒng)的高命中率。性能測(cè)試主要包括在兩種情況下，即有緩存層和epoll接口層的NuptCache系統(tǒng)與只使用優(yōu)化后的磁盤數(shù)據(jù)庫mysql的環(huán)境下，在系統(tǒng)并發(fā)量處理數(shù)量和數(shù)據(jù)請(qǐng)求的系統(tǒng)平均處理時(shí)間的對(duì)比。

圖5系統(tǒng)的并發(fā)處理時(shí)間對(duì)比圖圖6相同并發(fā)量數(shù)據(jù)請(qǐng)求的系統(tǒng)平均處理時(shí)間測(cè)試圖5系統(tǒng)的并發(fā)處理時(shí)間對(duì)比圖圖6相同并發(fā)量數(shù)據(jù)請(qǐng)求的系統(tǒng)平均處理時(shí)間測(cè)試我們可以清楚的從圖5上看出，在并發(fā)數(shù)達(dá)到2000時(shí)，mysql數(shù)據(jù)庫由于本身并發(fā)數(shù)的限制，拒絕繼續(xù)測(cè)試，而NuptCache系統(tǒng)在處理10000并發(fā)連接時(shí)，仍能夠穩(wěn)定運(yùn)行，時(shí)間查詢消耗僅0.49s。從圖6中可以看出，在相同并發(fā)量請(qǐng)求的情況下的數(shù)據(jù)查詢消耗時(shí)間，隨著緩存層數(shù)據(jù)量的增大，并沒有明顯的加長(zhǎng)。和只有優(yōu)化過的mysql磁盤數(shù)據(jù)庫相比，有著明顯的優(yōu)勢(shì)。這和NuptCache系統(tǒng)的分布式散列對(duì)象到不同的memcached緩存服務(wù)器，查詢復(fù)雜度是O(1)有很大的關(guān)系。5結(jié)束語文中指出傳統(tǒng)數(shù)據(jù)存儲(chǔ)和處理的模式在為海量用戶服務(wù)時(shí)的不足，提出了一種高性能分布式緩存系統(tǒng)NuptCache的原型，系統(tǒng)采用了epoll加多線程模型來提高系統(tǒng)的吞吐量，通過memcached緩存服務(wù)器與mysql磁盤數(shù)據(jù)庫進(jìn)行的數(shù)據(jù)冗余機(jī)制提升命中率。文中還對(duì)NuptCache系統(tǒng)進(jìn)行了詳細(xì)的功能和性能測(cè)試，功能測(cè)試包括系統(tǒng)能否處理大并發(fā)量的請(qǐng)求，能否對(duì)NuptCache系統(tǒng)的緩存層中存放的熱點(diǎn)數(shù)據(jù)進(jìn)行查詢，能否對(duì)在緩存層中未存儲(chǔ)的數(shù)據(jù)進(jìn)行處理并同步至緩存；性能測(cè)試主要包括系統(tǒng)并發(fā)量處理能力和系統(tǒng)處理請(qǐng)求數(shù)據(jù)的平均時(shí)間的對(duì)比，突出NuptCache系統(tǒng)的性能優(yōu)勢(shì)，為今后的高并發(fā)、分布式的數(shù)據(jù)服務(wù)系統(tǒng)的設(shè)計(jì)提供一個(gè)新的思路。參考文獻(xiàn)：MitraNasri,MohsenSharifi.LoadBalancingUsingConsistentHashing:ARealChallengeforLargeScaleDistributedWebCrawlers[R].Proceedingsofthe2009InternationalConferenceonAdvancedInformationNetworkingandApplicationsWorkshops,pages715-720,2009.05.sys_epoll-makingpollfast[EB/OL]./Articles/14168,2005.LouayGammo,TimBrecht,AmolShuklaandDavidPariag.Com