吞吐量對服務(wù)端框架的處理效率有著重要的影響,為了進(jìn)一步提升傳統(tǒng)服務(wù)端框架的吞吐量,提出了一種基于Reactor模式與非阻塞IO的服務(wù)端框架。首先,對Reactor模式與非阻塞IO進(jìn)行了優(yōu)勢分析,并闡述了Reactor線程池的分發(fā)邏輯;其次,通過設(shè)計(jì)自適應(yīng)緩沖區(qū)結(jié)構(gòu)降低了內(nèi)存分配次數(shù),提升了數(shù)據(jù)讀入和寫出的效率;最后,通過設(shè)計(jì)雙緩沖結(jié)構(gòu)優(yōu)化了日志的寫入操作,提升了日志寫入效率。實(shí)驗(yàn)結(jié)果顯示:在單線程測試環(huán)境下,對比libevent,該服務(wù)端框架吞吐量平均提升了9%;在多線程測試環(huán)境下,分別在100連接與1000連接時(shí),對比Boost.Asio,該服務(wù)端框架吞吐量分別平均提升了28.66%與20.76%。這表明該服務(wù)端框架吞吐量較高,可應(yīng)用于較大數(shù)據(jù)量請求的場景。 

【文章來源】：浙江理工大學(xué)學(xué)報(bào)(自然科學(xué)版). 2020,43(04)

【文章頁數(shù)】：7 頁

【部分圖文】：

Reactor模式流程示意圖

本文服務(wù)端總體框架主要分為四個(gè)模塊:Reactor線程池、自適應(yīng)緩沖區(qū)、雙緩沖日志以及任務(wù)線程池。多個(gè)請求狀態(tài)下的時(shí)序圖如圖2所示。其中Epoll為多路復(fù)用機(jī)制的一種;Connection為發(fā)出請求的連接;Accept、Read和Write為網(wǎng)絡(luò)編程系統(tǒng)函數(shù);Encode、Decode和Compute為服務(wù)端開發(fā)過程中常見的編碼、解碼以及計(jì)算流程;Wait表示線程池空閑時(shí)長。當(dāng)連接connection1成為活動(dòng)連接時(shí),主反應(yīng)堆Base Reactor監(jiān)聽到該事件后,將Accept函數(shù)返回的文件描述通過Round robin的方式分發(fā)給反應(yīng)堆進(jìn)行當(dāng)讀、寫、編解碼等操作,其中數(shù)據(jù)的收發(fā)都先經(jīng)過自適應(yīng)緩沖區(qū)的處理,待數(shù)據(jù)接收完整時(shí)再遞交應(yīng)用層做進(jìn)一步處理。應(yīng)用層處理過程中,如果其中某個(gè)操作較為耗時(shí),為了不阻塞IO線程,則將耗時(shí)操作遞交給線程池做進(jìn)一步處理,以盡快空出IO線程,使線程得到最大程度的復(fù)用,從而提升服務(wù)端框架整體的吞吐量。同時(shí)子反應(yīng)堆的數(shù)量以及線程池中線程的數(shù)量在服務(wù)端程序啟動(dòng)時(shí)就已經(jīng)確定,當(dāng)遇到突發(fā)請求時(shí)處理能力不會(huì)隨著請求數(shù)量的急劇增多而陡然降低,也不會(huì)因?yàn)镮O線程由于長時(shí)間被耗時(shí)操作所占據(jù)從而影吞吐量甚至失去響應(yīng)[14]。2.1 核心接口設(shè)計(jì)

框架核心接口的類圖如圖3所示,主要有ReacotrLoop、ReactorAcceptor、ReactorChannel、TcpConnection和ThreadPool等。a)ReacotrLoop類。該類適用于多路復(fù)用機(jī)制,主要功能有:向epoll中注冊服務(wù)端程序所關(guān)心的事件,如連接建立事件、可讀可寫事件等;通過多路復(fù)用機(jī)制,在內(nèi)核對這些事件進(jìn)行監(jiān)聽,當(dāng)所監(jiān)聽的事件變?yōu)榛顒?dòng)時(shí),將該事件與子反應(yīng)堆進(jìn)行綁定,即派發(fā)給相應(yīng)的ReactorChannel進(jìn)行處理。


本文編號：3469938