摘  要： 為了解決多維服務(wù)網(wǎng)關(guān)因高并發(fā)情況而導(dǎo)致的網(wǎng)絡(luò)擁塞、服務(wù)器性能降低問(wèn)題，提出了一種改進(jìn)的線程池服務(wù)器設(shè)計(jì)方法。首先根據(jù)經(jīng)驗(yàn)值創(chuàng)建一個(gè)尺寸最優(yōu)的線程池，并結(jié)合SQLite數(shù)據(jù)庫(kù)為線程池添加一個(gè)瞬時(shí)同類服務(wù)請(qǐng)求合并模塊。該模塊對(duì)請(qǐng)求連接進(jìn)行分類，劃分優(yōu)先級(jí)，然后根據(jù)不同的請(qǐng)求優(yōu)先級(jí)把與其優(yōu)先級(jí)對(duì)應(yīng)的Tl秒內(nèi)的同類請(qǐng)求合并為1個(gè)請(qǐng)求，以此來(lái)降低整個(gè)服務(wù)過(guò)程的時(shí)延，提高請(qǐng)求響應(yīng)速度。實(shí)驗(yàn)表明，該設(shè)計(jì)能夠有效地降低高并發(fā)情況下的擁塞現(xiàn)象，并降低網(wǎng)絡(luò)時(shí)延。

　　關(guān)鍵詞： 多維網(wǎng)關(guān)；多任務(wù)處理；高并發(fā)；線程池

　　在信息化、數(shù)字化的今天，計(jì)算機(jī)網(wǎng)絡(luò)已經(jīng)完全融入了人類的生活、生產(chǎn)當(dāng)中[1]。人與人之間可以通過(guò)網(wǎng)絡(luò)進(jìn)行信息傳遞和資源共享，人與物、物與物之間也可以通過(guò)網(wǎng)絡(luò)進(jìn)行交流。多維Web服務(wù)網(wǎng)關(guān)就是在這種背景下提出的。多維Web服務(wù)網(wǎng)關(guān)是融合了當(dāng)前互聯(lián)網(wǎng)技術(shù)、嵌入式技術(shù)、無(wú)線傳感網(wǎng)技術(shù)和Web Service技術(shù)的一種可以為互聯(lián)網(wǎng)用戶提供所監(jiān)測(cè)環(huán)境的實(shí)時(shí)數(shù)據(jù)并可以對(duì)其進(jìn)行控制的網(wǎng)關(guān)。該網(wǎng)關(guān)最大的特點(diǎn)是使用了Web Service技術(shù)，這種技術(shù)給互聯(lián)網(wǎng)用戶提供了一種平臺(tái)獨(dú)立、松耦合、自包含、基于可編程的Web應(yīng)用程序，可以使用開放的XML標(biāo)準(zhǔn)來(lái)描述、發(fā)布、發(fā)現(xiàn)、協(xié)調(diào)和配置這些應(yīng)用程序。多維Web服務(wù)網(wǎng)關(guān)的關(guān)鍵核心技術(shù)是處理來(lái)自互聯(lián)網(wǎng)用戶的請(qǐng)求，并從底層的傳感網(wǎng)中讀取相應(yīng)的數(shù)據(jù)并反饋給用戶。

　　由于多維服務(wù)網(wǎng)關(guān)提供的是開放的可供查詢的服務(wù)，因此很可能遭遇到瞬時(shí)大量用戶訪問(wèn)的情況(高并發(fā)情況)。針對(duì)該情況，傳統(tǒng)的基于多線程和Select機(jī)制的并發(fā)服務(wù)器由于受到系統(tǒng)硬件資源的限制，已經(jīng)不能滿足高實(shí)時(shí)性、高可靠性的要求了。另外由于多維網(wǎng)關(guān)有WiFi、千兆以太網(wǎng)端口、3G、ZigBee等多種信道，各種信道的傳輸速率不同，這也會(huì)增加服務(wù)器出現(xiàn)擁塞狀況。

　　針對(duì)多維網(wǎng)關(guān)所出現(xiàn)的各種問(wèn)題，本文設(shè)計(jì)了一種改進(jìn)的線程池解決方案。該方案對(duì)經(jīng)典的線程池設(shè)計(jì)模式進(jìn)行改進(jìn)后，首次應(yīng)用在多維網(wǎng)關(guān)上，并作為多維網(wǎng)關(guān)處理消息轉(zhuǎn)發(fā)的一種核心技術(shù)，有效地解決了多維Web服務(wù)網(wǎng)關(guān)在高并發(fā)情況下的擁塞問(wèn)題。

　　1 傳統(tǒng)的多線程高并發(fā)服務(wù)器的原理及實(shí)現(xiàn)技術(shù)

　　早期的服務(wù)器采用多進(jìn)程來(lái)解決高并發(fā)問(wèn)題，但是進(jìn)程的創(chuàng)建開銷很大，對(duì)服務(wù)器性能要求比較高，相比較而言線程的資源開銷比進(jìn)程小得多，而且子線程的創(chuàng)建速度快，同一進(jìn)程內(nèi)的子線程之間進(jìn)行切換花費(fèi)也小，子線程之間的通信也易實(shí)現(xiàn)，所以多線程技術(shù)很快取代了多進(jìn)程用于高并發(fā)服務(wù)器的設(shè)計(jì)上[2]。

　　多線程技術(shù)雖然比多進(jìn)程在一定程度上改善了服務(wù)器性能，但卻存在著致命的缺陷。首先大量用戶請(qǐng)求所帶來(lái)的線程不停地創(chuàng)建和銷毀，將會(huì)消耗CPU大量的處理時(shí)間，也會(huì)造成響應(yīng)的時(shí)延，從而使得網(wǎng)絡(luò)擁塞[3-4]。線程池技術(shù)的利用大大改善了服務(wù)器在高并發(fā)情況下的性能下降問(wèn)題，該技術(shù)通過(guò)在程序開始時(shí)創(chuàng)建一批線程來(lái)處理到來(lái)的用戶請(qǐng)求，用戶請(qǐng)求多于線程池線程數(shù)目時(shí)可以把請(qǐng)求任務(wù)暫時(shí)放在任務(wù)隊(duì)列中，等線程池中有了空閑的線程再?gòu)娜蝿?wù)隊(duì)列中取出任務(wù)交給空閑線程去處理；當(dāng)用戶請(qǐng)求少于線程池線程數(shù)目時(shí)，空閑線程掛起等待[5]。

　　2 改進(jìn)的線程池算法的提出

　　2.1 傳統(tǒng)線程池應(yīng)用與多維Web服務(wù)網(wǎng)關(guān)的缺陷

　　簡(jiǎn)單線程池存在的問(wèn)題是：如果有大量的客戶要求服務(wù)器為其服務(wù)，但由于線程池的工作線程是有限的，服務(wù)器只能為部分客戶服務(wù)，其他客戶提交的任務(wù)只能在任務(wù)隊(duì)列中等待處理。這種狀況直接增加了服務(wù)網(wǎng)關(guān)的響應(yīng)時(shí)間，所以調(diào)整優(yōu)化線程池尺寸是高級(jí)線程池要解決的一個(gè)問(wèn)題。另外，由于多維Web服務(wù)網(wǎng)關(guān)要與底層的無(wú)線傳感網(wǎng)通信來(lái)獲取實(shí)時(shí)數(shù)據(jù)，假設(shè)服務(wù)器解析用戶請(qǐng)求的時(shí)間為T1，服務(wù)器從傳感網(wǎng)中相應(yīng)的節(jié)點(diǎn)獲取數(shù)據(jù)的時(shí)間為T2，請(qǐng)求和響應(yīng)在互聯(lián)網(wǎng)中的傳輸時(shí)間為T3，完成單次用戶請(qǐng)求任務(wù)的總時(shí)間為T，則有：

　　T=T1+T2+T3(1)

　　T2>>T1(2)

　　T3>>T1(3)

　　所以，對(duì)于多維網(wǎng)關(guān)來(lái)說(shuō)，降低T2和T3的時(shí)間也是比較有效的策略。綜上，本文對(duì)簡(jiǎn)單的線程池提出了如下兩點(diǎn)改進(jìn)：

　　(1)優(yōu)化工作線程數(shù)目。根據(jù)統(tǒng)計(jì)學(xué)的原理來(lái)統(tǒng)計(jì)客戶的請(qǐng)求數(shù)目，比如高峰時(shí)段平均1 s內(nèi)有多少任務(wù)要求處理，并根據(jù)系統(tǒng)的承受能力及客戶的忍受能力來(lái)平衡估計(jì)一個(gè)合理的線程池尺寸。

　　(2)給線程池添加瞬時(shí)同類請(qǐng)求合并模塊。由于網(wǎng)絡(luò)用戶對(duì)多維網(wǎng)關(guān)的請(qǐng)求大部分為數(shù)據(jù)請(qǐng)求，控制請(qǐng)求比較少，并且控制請(qǐng)求在時(shí)間上不太集中，因此將短時(shí)間T1內(nèi)的大量同類數(shù)據(jù)請(qǐng)求合并為一個(gè)請(qǐng)求，而對(duì)于控制請(qǐng)求則不予合并直接通過(guò)該模塊。根據(jù)式(1)～式(3)可知，減少對(duì)底層傳感網(wǎng)的訪問(wèn)能有效地降低整個(gè)網(wǎng)絡(luò)時(shí)延。假設(shè)：網(wǎng)關(guān)收到的請(qǐng)求中數(shù)據(jù)請(qǐng)求占90%，控制請(qǐng)求和服務(wù)描述請(qǐng)求各占5%，網(wǎng)關(guān)對(duì)底層的無(wú)線傳感網(wǎng)訪問(wèn)一次耗時(shí)為Tw；網(wǎng)關(guān)提供了10個(gè)服務(wù)，其中提供數(shù)據(jù)的服務(wù)和提供控制的服務(wù)各占一半；網(wǎng)關(guān)1 s內(nèi)收到了N個(gè)服務(wù)請(qǐng)求，那么使用簡(jiǎn)單線程池的服務(wù)網(wǎng)關(guān)完成N個(gè)請(qǐng)求要花費(fèi)在底層傳感網(wǎng)訪問(wèn)的時(shí)間為Tb，使用添加了合并模塊的線程池服務(wù)網(wǎng)關(guān)所花費(fèi)時(shí)間為Ta，其中Tl設(shè)置為1 s，則有：

　　Tb=N×95%×Tw(4)

　　Ta=(N×5%+10×50%)×Tw(5)

　　當(dāng)N=100時(shí)，Tb=95 Tw，Ta=10 Tw；當(dāng)N=500時(shí)，Tb=475 Tw，Ta=30 Tw。所以當(dāng)訪問(wèn)量越多時(shí)，改進(jìn)后的算法優(yōu)勢(shì)越明顯。

　　2.2 改進(jìn)后的線程池設(shè)計(jì)流程

　　如圖1所示，改進(jìn)后的算法分為兩大部分，添加了瞬時(shí)同類請(qǐng)求合并模塊，線程池中每個(gè)工作線程中的任務(wù)都要經(jīng)過(guò)該模塊的過(guò)濾才可以訪問(wèn)底層的傳感網(wǎng)。

　　圖2給出了瞬時(shí)同類請(qǐng)求合并模塊的詳細(xì)流程圖，算法的基本思想是對(duì)實(shí)時(shí)性要求比較高的控制類請(qǐng)求進(jìn)行直接轉(zhuǎn)發(fā)，對(duì)于數(shù)據(jù)請(qǐng)求在允許的時(shí)間內(nèi)對(duì)其進(jìn)行合并。也就是在瞬時(shí)Tl內(nèi)對(duì)首個(gè)數(shù)據(jù)請(qǐng)求直接轉(zhuǎn)發(fā)給傳感網(wǎng)絡(luò)，讀取數(shù)據(jù)后把結(jié)果返回給客戶端，同時(shí)在服務(wù)器數(shù)據(jù)庫(kù)中插入該條數(shù)據(jù)和請(qǐng)求類型，并設(shè)置一個(gè)時(shí)間為Tl的定時(shí)器，定時(shí)器到時(shí)間后即刪除該條數(shù)據(jù)。新到的同類請(qǐng)求不再訪問(wèn)傳感網(wǎng)絡(luò)，而是直接檢查數(shù)據(jù)庫(kù)是否有同類請(qǐng)求，有則直接從數(shù)據(jù)庫(kù)讀取數(shù)據(jù)并返回給客戶端；否則重復(fù)以上步驟。該設(shè)計(jì)使用了SQLite數(shù)據(jù)庫(kù)，由于SQLite是一個(gè)使用C代碼編寫的小型數(shù)據(jù)庫(kù)，大小不足270 KB，讀寫速度非?？?，特別適合嵌入式設(shè)備。

　　Tl是從數(shù)據(jù)獲取到失效的生存時(shí)間，每個(gè)生存時(shí)間與請(qǐng)求的優(yōu)先級(jí)有關(guān)。每個(gè)服務(wù)請(qǐng)求都設(shè)置一個(gè)用戶時(shí)間容忍度ρ。網(wǎng)絡(luò)請(qǐng)求超時(shí)極值為T(T的值為50 s)。則Tl的取值為：

　　Tl=T×ρ(6)

　　容忍度ρ的取值范圍為0～1，實(shí)時(shí)性要求越高的服務(wù)其ρ的取值越小，控制類的ρ取值一律為0。當(dāng)某個(gè)請(qǐng)求量很大時(shí)，其ρ的取值也會(huì)增大。ρ的計(jì)算公式為：

　　其中，n為在30 min內(nèi)的請(qǐng)求總數(shù)。

　　3 對(duì)比測(cè)試及結(jié)果分析

　　本文使用C語(yǔ)言在Linux系統(tǒng)下實(shí)現(xiàn)了改進(jìn)后線程池算法，并對(duì)其性能進(jìn)行了測(cè)試。下面是使用jmeter壓力測(cè)試工具對(duì)改進(jìn)前后的線程池算法服務(wù)器和多線程服務(wù)器進(jìn)行的對(duì)比測(cè)試，測(cè)試環(huán)境均為L(zhǎng)inux(2.6內(nèi)核)，Inter Pentium Dual E2180處理器，512 MB內(nèi)存。

　　(1)選擇最優(yōu)線程池尺寸測(cè)試

　　改變線程池的大小，任務(wù)數(shù)設(shè)置為2 000，對(duì)多線程的服務(wù)器進(jìn)行測(cè)試。

　　如圖3所示，線程池容量在32之前一直比較穩(wěn)定，并維持在非常好的效果，明顯優(yōu)于多線程服務(wù)算法。容量在32之后線程池算法服務(wù)器性能開始下降，特別是在128之后，性能下降明顯，在300之后性能差于多線程服務(wù)器。線程池尺寸可以選擇8~32個(gè)線程。

　　(2)3種算法對(duì)比測(cè)試結(jié)果

　　根據(jù)第一次測(cè)試結(jié)果選取線程池大小固定為16個(gè)線程，改進(jìn)后的線程池算法的瞬時(shí)同類請(qǐng)求合并模塊時(shí)間參數(shù)設(shè)置為0.5 s。改變?nèi)蝿?wù)數(shù)對(duì)3種服務(wù)器進(jìn)行再次測(cè)試。

　　如圖4所示，線程池算法表現(xiàn)比較穩(wěn)定。在任務(wù)數(shù)為64個(gè)之前，3種算法服務(wù)器的性能差別不明顯；在任務(wù)數(shù)為128之后性能開始出現(xiàn)差異，特別是任務(wù)數(shù)在256之后，改進(jìn)后的線程池算法明顯優(yōu)于多線程算法服務(wù)器；在任務(wù)數(shù)達(dá)到512個(gè)之后，改進(jìn)后的線程池算法開始體現(xiàn)出明顯的優(yōu)勢(shì)。

　　參考文獻(xiàn)

　　[1] 黃冬泉.高并發(fā)事件驅(qū)動(dòng)服務(wù)器研究[J].計(jì)算機(jī)工程與科學(xué)，2007，29(1)：138-141.

　　[2] 許永達(dá).基于線程池的高并發(fā)訪問(wèn)考試系統(tǒng)設(shè)計(jì)[J].計(jì)算機(jī)與現(xiàn)代化，2013，4(3)：232-234.

　　[3] 孫旭東，韓江洪，劉征宇，等.基于分段的線程池尺寸自適應(yīng)調(diào)整算法[J].計(jì)算機(jī)工程，2013，37(2)：43-44.

　　[4] 楊開杰，劉秋菊，徐汀榮.線程池的多線程并發(fā)控制技術(shù)研究[J].計(jì)算機(jī)應(yīng)用與軟件，2010，27(1)：168-170.

　　[5] 唐富強(qiáng)，于鴻洋，張萍.Linux下通用線程池的改進(jìn)與實(shí)現(xiàn)[J].計(jì)算機(jī)工程與應(yīng)用，2012，48（28）：77-83.