引 言

對(duì)等網(wǎng)絡(luò)P2P（Peer-to-peer）技術(shù)是目前國(guó)際計(jì)算機(jī)網(wǎng)絡(luò)技術(shù)領(lǐng)域研究的一個(gè)熱點(diǎn)。該技術(shù)的雛形產(chǎn)生于20世紀(jì)70年代，典型代表是UseNet和FidoNet；而CDN內(nèi)容分發(fā)網(wǎng)絡(luò)（Content Distri-bution Network）則是將網(wǎng)站的內(nèi)容或媒體發(fā)布到最接近用戶的網(wǎng)絡(luò)“邊緣”，當(dāng)用戶訪問(wèn)時(shí)，系統(tǒng)自動(dòng)無(wú)縫地把用戶重定向到邊緣服務(wù)器，從而減輕中心服務(wù)器和主干網(wǎng)絡(luò)的壓力，提升流媒體或網(wǎng)站的性能。

隨著網(wǎng)絡(luò)技術(shù)的迅猛發(fā)展，流媒體內(nèi)容在互聯(lián)網(wǎng)中大量傳播，對(duì)于高質(zhì)量的流媒體分發(fā)服務(wù)體現(xiàn)得越加明顯，因而為大量用戶提供快速，高質(zhì)量的流媒體分發(fā)服務(wù)成為了最近研究的熱點(diǎn)和難點(diǎn)。

在多媒體監(jiān)控系統(tǒng)中所要傳輸?shù)臄?shù)據(jù)量是相當(dāng)大的，主要包括：控制信息、反饋信息、視頻、音頻和其他如文本信息等。對(duì)于傳統(tǒng)的基于C／S模式或B／S模式的多媒體監(jiān)控系統(tǒng)，在監(jiān)控點(diǎn)和監(jiān)控中心之間進(jìn)行這些大量流媒體數(shù)據(jù)傳輸，服務(wù)器性能會(huì)直線下降?；诖吮疚陌裀2P技術(shù)引入到該多媒體監(jiān)控系統(tǒng)設(shè)計(jì)中主要做了如下改進(jìn)：

（1）設(shè)計(jì)了基于P2P和CDN的監(jiān)控傳輸子系統(tǒng)。

（2）客戶利用P2P方式從邊緣服務(wù)器得到服務(wù)，同時(shí)原始服務(wù)器和邊緣服務(wù)器之間的內(nèi)容發(fā)布也通過(guò)P2P方式進(jìn)行，通過(guò)這種方式有效地利用了系統(tǒng)中網(wǎng)絡(luò)帶寬和主機(jī)資源，減輕了原始服務(wù)器和邊緣服務(wù)器的壓力，減少了主干網(wǎng)數(shù)據(jù)流量，降低了運(yùn)營(yíng)商的成本，提高了客戶的服務(wù)質(zhì)量。

（3）為了緩解網(wǎng)絡(luò)I／O和磁盤I／O的矛盾，在傳輸子系統(tǒng)的設(shè)計(jì)中采用半同步／半異步的方式將網(wǎng)絡(luò)I／O與磁盤I／O分開，并通過(guò)任務(wù)池的方式進(jìn)行緩沖。

（4）設(shè)計(jì)了線程池動(dòng)態(tài)管理算法，有效減小了CPU的負(fù)載壓力，提高了網(wǎng)絡(luò)吞吐量和系統(tǒng)整體性能。

（5）針對(duì)傳統(tǒng)方式的缺點(diǎn)進(jìn)行了有效的改進(jìn)，利用半同步／半異步的方式建立系統(tǒng)框架，利用任務(wù)池對(duì)數(shù)據(jù)的讀寫請(qǐng)求進(jìn)行封裝，采用線程池對(duì)任務(wù)池中的任務(wù)進(jìn)行高效異步處理。通過(guò)對(duì)任務(wù)的閑置情況進(jìn)行統(tǒng)計(jì)，并結(jié)合系統(tǒng)的當(dāng)前資源利用情況，對(duì)任務(wù)池和線程池進(jìn)行動(dòng)態(tài)管理，降低了CPU的負(fù)載，提高了系統(tǒng)的吞吐量。

2 系統(tǒng)框架

系統(tǒng)總體布局如圖1所示，邊緣服務(wù)器將會(huì)與若干客戶節(jié)點(diǎn)形成P2P網(wǎng)絡(luò)，提供高效的服務(wù)質(zhì)量，便于降低服務(wù)器的負(fù)載。

當(dāng)客戶在邊緣服務(wù)器上請(qǐng)求資源不命中時(shí)，邊緣服務(wù)器會(huì)向原始服務(wù)器請(qǐng)求，原始服務(wù)器會(huì)根據(jù)具體請(qǐng)求要求，將需要的媒體資源通過(guò)該文實(shí)現(xiàn)的高效傳輸子系統(tǒng)存儲(chǔ)在本地，然后利用P2P的方式向多個(gè)邊緣服務(wù)器發(fā)布內(nèi)容。

通過(guò)這種方式有效減輕了原始服務(wù)器在內(nèi)容發(fā)布時(shí)的壓力。理論上它只要將一個(gè)完整的媒體副本發(fā)送出去，其他邊緣服務(wù)器會(huì)根據(jù)P2P的方式得到一個(gè)完整的副本。同理，當(dāng)邊緣服務(wù)器向客戶提供服務(wù)時(shí)，理論上它也只需要傳輸一個(gè)副本，多個(gè)客戶端就可以得到完整的服務(wù)。原始服務(wù)器和媒體資源服務(wù)器通常是在一個(gè)子網(wǎng)中，網(wǎng)絡(luò)速度比磁盤I／O速度更快。此時(shí)，磁盤I／O成了系統(tǒng)的瓶頸。為了緩解網(wǎng)絡(luò)I／O和磁盤1／O的矛盾，在傳輸子系統(tǒng)的設(shè)計(jì)當(dāng)中采用半同步／半異步的方式將網(wǎng)絡(luò)I／O與磁盤I／O分離開，并通過(guò)任務(wù)池的方式進(jìn)行緩沖。

上層的主線程處理epoll異步事件和協(xié)議交互，框架將接收到的數(shù)據(jù)按照固定大小封裝在任務(wù)里面，然后將任務(wù)放回任務(wù)池，下層線程池負(fù)責(zé)從任務(wù)池中取出任務(wù)，進(jìn)行具體的磁盤讀寫操作，操作完成后線程和任務(wù)分別回到線程池和任務(wù)池等待調(diào)度。

3 算法實(shí)現(xiàn)

為了對(duì)線程池進(jìn)行有效的動(dòng)態(tài)管理，需要采集各種性能參數(shù)，經(jīng)過(guò)綜合分析之后，對(duì)線程池做出調(diào)整。該算法中參考了兩個(gè)最關(guān)鍵的參數(shù)，即任務(wù)的平均等待時(shí)間和CPU使用率。通過(guò)任務(wù)的平均等待時(shí)間，可以分析得到當(dāng)前線程池需要調(diào)整的方向。通過(guò)CPU使用率可以得到是否需要增加或者減少線程。

圖2中c（current）表示線程池當(dāng)前平均等待時(shí)間；p（previous）表示線程池上次等待時(shí)間；pp表示上上次等待時(shí)間；ps（pool size）表示線程池大?。籶ps表示上次線程池大小。該算法中并不是對(duì)等待時(shí)間的絕對(duì)值進(jìn)行比較，而是對(duì)currTime和preTime進(jìn)行比較，如果差異大于1％，線程池可能需要調(diào)整，調(diào)整方向需要根據(jù)currTime和preTime的大小關(guān)系來(lái)決定。如果currTime大于preTime，需要進(jìn)一步比較pre-Time和prepreTime的關(guān)系；如果preTime小于prepreTime，并且CPU使用率大于90％，那么減小線程池。減小的步長(zhǎng)（stride）為2。如果preTime大于prepreTime，并且CPU使用率小于80％，則增大線程池，增加的步長(zhǎng)為2。如果currTime小于preTime，并且preTime小于prepreTime，則增大線程池。

簡(jiǎn)而言之，算法通過(guò)對(duì)currTime，preTime，prepre-

Time三者的關(guān)系進(jìn)行比較，確定線程池是否需要調(diào)整。

當(dāng)需要減小線程池時(shí)，需要進(jìn)一步判斷CPU的使用率，只有CPU大于一個(gè)閥值時(shí)才進(jìn)行減小操作，因?yàn)镃PU的負(fù)載太小也是一種資源浪費(fèi)；同理，當(dāng)需要增大線程池時(shí)，也只能在CPU小于一個(gè)閥值時(shí)，才能進(jìn)行增加操作，因?yàn)镃PU的負(fù)載不能過(guò)大。

4 實(shí)驗(yàn)分析

因?yàn)槊襟w資源服務(wù)器和原始服務(wù)器多在同一個(gè)子網(wǎng)中，因此實(shí)驗(yàn)的環(huán)境也通過(guò)一個(gè)局域網(wǎng)模擬，服務(wù)器的基本配置是：兩個(gè)Intel雙核Xeon 3 GHz芯片、2 048 KB緩存、4 GB內(nèi)存、1 000 Mb／s網(wǎng)卡。

4．1 三種模型的實(shí)驗(yàn)數(shù)據(jù)

實(shí)驗(yàn)通過(guò)傳輸子系統(tǒng)從負(fù)載發(fā)生器下載數(shù)據(jù)來(lái)模擬大量數(shù)據(jù)請(qǐng)求，并分別收集下列三種模型的實(shí)驗(yàn)數(shù)據(jù)：

（1）傳統(tǒng)多線程阻塞模型，即每個(gè)現(xiàn)存阻塞得處理一個(gè)單獨(dú)的請(qǐng)求，在圖3中用A表示，并簡(jiǎn)稱為A模型。

（2）固定線程數(shù)目的線程池，初試線程數(shù)采用CPU個(gè)數(shù)的2倍加2來(lái)確定，即10個(gè)初始線程，在圖3中用B表示，并簡(jiǎn)稱為B模型。

（3）采用該文提出的線程池動(dòng)態(tài)管理算法的模型，初試線程個(gè)數(shù)也為10個(gè)，在圖3中用C表示，并簡(jiǎn)稱C模型。

4．2 分析數(shù)據(jù)得平均值

下面數(shù)據(jù)均是通過(guò)nmon采樣和ninon analyser分析得到的平均值。

（1）CPU使用率比較。從圖3中可以看到，在A模型中，基本已經(jīng)占用了所有的CPU資源。因?yàn)槊總€(gè)線程服務(wù)一個(gè)請(qǐng)求，一旦請(qǐng)求大量到來(lái)，就會(huì)有大量的線程產(chǎn)生。而在B模型中，因?yàn)榫€程個(gè)數(shù)固定，且已經(jīng)預(yù)先創(chuàng)建好，當(dāng)請(qǐng)求量過(guò)大時(shí)，任務(wù)隊(duì)列會(huì)起到很好的緩沖作用。C模型是效果最好的，因?yàn)榫€程個(gè)數(shù)總是會(huì)被調(diào)整到最佳的個(gè)數(shù)，并且任務(wù)池的使用有效減少了系統(tǒng)中頻繁的內(nèi)存申請(qǐng)和釋放操作。

（2）空閑內(nèi)存比較。從圖4中可以容易分析得到，當(dāng)請(qǐng)求的總量相同的情況下，A和B模型占用的內(nèi)存情況很接近。但是C模型中，任務(wù)池和線程池的大小都是動(dòng)態(tài)伸縮的，提高了系統(tǒng)的處理能力，自然也會(huì)使用更多的內(nèi)存。

（3）網(wǎng)絡(luò)I／O流量比較。圖5展現(xiàn)了3種模型的網(wǎng)絡(luò)I／O情況，在A模型中，因?yàn)椴捎玫氖亲枞姆绞竭M(jìn)行的，當(dāng)套口已經(jīng)沒有數(shù)據(jù)可讀，線程會(huì)阻塞等待數(shù)據(jù)的到達(dá)，而其他已經(jīng)有數(shù)據(jù)到達(dá)的套接口則可能得不到處理，因此A模型的網(wǎng)絡(luò)吞吐量比較低。在B模型中，采用的非阻塞和線程池模型，一旦一個(gè)套接口將要發(fā)生阻塞，線程可以很快切換到其他已經(jīng)有數(shù)據(jù)準(zhǔn)備好的套接口上，加快了數(shù)據(jù)的接收速度，因此也提高了網(wǎng)絡(luò)的傳輸速度。在C模型中，減小了內(nèi)存和CPU等部件的負(fù)載，提高了性能，動(dòng)態(tài)任務(wù)池使得系統(tǒng)有比B模型更好的緩存能力，因此C模型比B模型網(wǎng)絡(luò)吞吐量更高是可以理解的。系統(tǒng)采用的是l 000 Mb／s網(wǎng)卡，基本達(dá)到了網(wǎng)卡的極限。

5 結(jié) 語(yǔ)

根據(jù)統(tǒng)計(jì)線程池中的各個(gè)線程的平均等待時(shí)間和當(dāng)前CPU的使用率，對(duì)線程池的尺寸進(jìn)行動(dòng)態(tài)的調(diào)整。利用這種線程池動(dòng)態(tài)管理算法，可以很好地適應(yīng)Internet上客戶請(qǐng)求突發(fā)性變化的情況。當(dāng)突然到來(lái)大量請(qǐng)求時(shí)，根據(jù)算法原理，可以增加適量的線程滿足額外的請(qǐng)求；當(dāng)請(qǐng)求變少以后，會(huì)將線程的數(shù)量減少，從而減輕系統(tǒng)的壓力。經(jīng)過(guò)實(shí)驗(yàn)分析比較可以得出，采用線程池動(dòng)態(tài)管理算法之后，有效減小了CPU的負(fù)載壓力，提高了網(wǎng)絡(luò)吞吐量和系統(tǒng)整體性能。但是，線程池的管理還有很多地方可以優(yōu)化，比如調(diào)整線程池尺寸都是以2為步長(zhǎng)進(jìn)行調(diào)整的，但是這個(gè)步長(zhǎng)是根據(jù)經(jīng)驗(yàn)得出來(lái)的，還沒有很好的理論依據(jù)。同時(shí)，可以增加更多的統(tǒng)計(jì)信息加入到算法的決策之中，提高算法的精確性。

這里實(shí)現(xiàn)了在多媒體監(jiān)控傳輸系統(tǒng)中P2P和CDN的結(jié)合，引入半同步／半異步的模式，設(shè)計(jì)了系統(tǒng)框架，引入任務(wù)池和線程池等技術(shù)，解決了媒體資源服務(wù)器和原始服務(wù)器之間的高效傳輸子系統(tǒng)的網(wǎng)絡(luò)瓶頸，設(shè)計(jì)了有效的線程池動(dòng)態(tài)管理算法。

責(zé)任編輯：gt