方國(guó)棟，張育釗

（華僑大學(xué)工學(xué)院，泉州362021）

0 引言

隨著網(wǎng)絡(luò)技術(shù)的發(fā)展，通信行業(yè)發(fā)生了翻天覆地的變化[1]。目前，基于IP 的網(wǎng)絡(luò)對(duì)講機(jī)應(yīng)用越來(lái)越廣泛[2-3]，當(dāng)大量網(wǎng)絡(luò)對(duì)講機(jī)同時(shí)向服務(wù)器發(fā)起數(shù)據(jù)轉(zhuǎn)發(fā)請(qǐng)求時(shí)，服務(wù)器需和對(duì)講機(jī)建立大量的網(wǎng)絡(luò)連接，此時(shí)面臨高并發(fā)問(wèn)題，若訪問(wèn)者采用TCP 的方式保持網(wǎng)絡(luò)連接時(shí)，交換機(jī)會(huì)因?yàn)楦卟l(fā)TCP 流到達(dá)瓶頸率崩潰[4-6]。

雖然服務(wù)器的計(jì)算性能和存儲(chǔ)能力均有了質(zhì)的飛躍，但普通服務(wù)器根本無(wú)法處理高并發(fā)請(qǐng)求。對(duì)于這種問(wèn)題，目前有兩種解決方案，即采取高端服務(wù)器和使用普通服務(wù)器集群。雖然高端服務(wù)器的計(jì)算性能和存儲(chǔ)能力比普通服務(wù)器更強(qiáng)，但產(chǎn)品少、價(jià)格高、運(yùn)行和維護(hù)成本高等因素限制了它的推廣使用。為此，構(gòu)建服務(wù)器集群[7]，通過(guò)組合多個(gè)普通服務(wù)器，形成一個(gè)高性能的服務(wù)器組，共同完成大量的存儲(chǔ)和計(jì)算等任務(wù)就成為了首選。而怎樣合理的將大量請(qǐng)求、計(jì)算和存儲(chǔ)等服務(wù)分布到集群上、更好的處理高并發(fā)請(qǐng)求、提升集群的擴(kuò)展性就成為了一個(gè)新的研究熱點(diǎn)。

目前對(duì)于服務(wù)器處理海量數(shù)據(jù)和高并發(fā)訪問(wèn)方面的研究，主要分為基于線程池和非線程池兩類方式。基于線程池的方式在實(shí)踐中更為常見(jiàn)，已發(fā)表大量研究成果[8-11]。武雪芳等人[8]根據(jù)網(wǎng)絡(luò)游戲服務(wù)器需滿足高并發(fā)和及時(shí)性的特點(diǎn)，設(shè)計(jì)了一套高效的網(wǎng)絡(luò)游戲服務(wù)器并發(fā)架構(gòu)，該方案采用服務(wù)器集群處理高并發(fā)請(qǐng)求，并選擇線程池策略提高響應(yīng)速度。樊揚(yáng)軻等人[9]通過(guò)結(jié)合epoll 和線程池技術(shù)，使服務(wù)器具有高并發(fā)處理的能力，其中epoll 技術(shù)用于做事件觸發(fā)，線程池技術(shù)用于處理客戶端請(qǐng)求。LING Yi-bei 等人[10]基于三個(gè)假設(shè)，即線程優(yōu)先級(jí)和CPU 時(shí)間一致、Web 請(qǐng)求的I/O資源和內(nèi)存均較小、并且系統(tǒng)資源可以整合到可觀察成本中，計(jì)算出了線程池所要?jiǎng)?chuàng)建的核心線程大小的最優(yōu)值，該方式能更有效的使用系統(tǒng)資源。劉新強(qiáng)等人[11]針對(duì)服務(wù)器需要不斷的創(chuàng)建線程并與大量客戶端通信時(shí)會(huì)消耗大量系統(tǒng)資源的問(wèn)題，給出了一種優(yōu)化方案以減少系統(tǒng)消耗。

線程池方式的結(jié)構(gòu)圖如圖1 所示。集群中每個(gè)通信節(jié)點(diǎn)先根據(jù)預(yù)先設(shè)置的核心線程數(shù)創(chuàng)建核心線程，當(dāng)大量的客戶端向集群發(fā)起通信請(qǐng)求時(shí)，如果通信節(jié)點(diǎn)線程池中沒(méi)有空閑線程，同時(shí)請(qǐng)求隊(duì)列已滿，節(jié)點(diǎn)將根據(jù)相應(yīng)的處理策略將請(qǐng)求隊(duì)列之前的請(qǐng)求丟棄或拒絕客戶端請(qǐng)求。如果節(jié)點(diǎn)線程池中有空閑線程，則給客戶端分配一個(gè)線程[12]，否則，如果請(qǐng)求隊(duì)列未滿，節(jié)點(diǎn)先將請(qǐng)求放到請(qǐng)求隊(duì)列中，直到線程池中有空閑線程時(shí)，再去請(qǐng)求隊(duì)列中取出請(qǐng)求，完成通信。這種方式只緩解了服務(wù)器創(chuàng)建線程時(shí)需要消耗的系統(tǒng)資源，但沒(méi)考慮如何聯(lián)合集群中的各通信節(jié)點(diǎn)。

圖1 線程池方式結(jié)構(gòu)圖

非線程池方式主要是通過(guò)多進(jìn)程和I/O 復(fù)用[13]、集群負(fù)載均衡等方式提升集群的高并發(fā)處理性能[14-15]。劉萬(wàn)軍等人[14]提出了基于蟻群算法的服務(wù)器集群資源調(diào)度算法，并引入等待因子的概念，采用等待因子動(dòng)態(tài)選取服務(wù)器資源，其目的在于解決各個(gè)服務(wù)器節(jié)點(diǎn)由于負(fù)載能力差異較大，導(dǎo)致集群服務(wù)器在提供服務(wù)的時(shí)候產(chǎn)生的木桶效應(yīng)，實(shí)驗(yàn)結(jié)果表明該方法可改善集群系統(tǒng)的整體性能和負(fù)載能力。段淮川等人[15]提出基于剩余負(fù)載率的動(dòng)態(tài)負(fù)載均衡機(jī)制。他設(shè)計(jì)了一種結(jié)合基于流表的靜態(tài)分配策略和基于負(fù)載預(yù)測(cè)的動(dòng)態(tài)分配策略的任務(wù)分配策略來(lái)實(shí)現(xiàn)在集群系統(tǒng)各節(jié)點(diǎn)間任務(wù)的動(dòng)態(tài)分配，降低服務(wù)器各節(jié)點(diǎn)之間任務(wù)重新調(diào)度的次數(shù)，達(dá)到提高集群系統(tǒng)的服務(wù)性能的目的。這種方式是為了提升高并發(fā)時(shí)集群的響應(yīng)速度和平衡各節(jié)點(diǎn)資源，做到“能者多勞”。其不足之處是沒(méi)有具體闡述如何維護(hù)集群各節(jié)點(diǎn)。

線程池方式和非線程池方式均沒(méi)有闡述如何在集群中做任務(wù)分發(fā)、如何高效的管理集群中各個(gè)節(jié)點(diǎn)。本文依據(jù)改進(jìn)型Chord[16-18]算法，提出面向網(wǎng)絡(luò)對(duì)講機(jī)語(yǔ)音小文件的高并發(fā)處理方案。仿真結(jié)果表明本文設(shè)計(jì)的服務(wù)器集群管理方案能對(duì)集群進(jìn)行有效的管理，并能合理對(duì)集群中服務(wù)器節(jié)點(diǎn)進(jìn)行任務(wù)分發(fā)，與使用線程池方式相比，本文方案的集群響應(yīng)時(shí)間減少了約40%。

1 高并發(fā)處理方案設(shè)計(jì)

1.1 Chord路由算法

Chord[17]是一種由UC Berkeley 與MIT 共同提出的分布式查找算法，目的是在對(duì)等網(wǎng)絡(luò)（P2P 網(wǎng)絡(luò)）中建立一個(gè)分布式、可擴(kuò)展和負(fù)載均衡的資源查找模式[19]。其文件查找過(guò)程的通信開(kāi)銷和系統(tǒng)維護(hù)的狀態(tài)隨著系統(tǒng)總節(jié)點(diǎn)數(shù)增加成指數(shù)關(guān)系[20]。Chord 網(wǎng)絡(luò)采用SHA-1 算法給每一個(gè)節(jié)點(diǎn)和關(guān)鍵字分配m bit 的標(biāo)識(shí)符[21]，標(biāo)識(shí)符范圍為[0～2m-1]，通常節(jié)點(diǎn)的標(biāo)識(shí)符為其IP 哈希值，關(guān)鍵字的標(biāo)識(shí)符為關(guān)鍵字哈希值，將所有標(biāo)識(shí)符模2m后按大小順時(shí)針排列組成Chord 環(huán)，如圖2 所示。關(guān)鍵字落在節(jié)點(diǎn)標(biāo)識(shí)符大于等于它的第一個(gè)節(jié)點(diǎn)上，稱為關(guān)鍵字的后繼節(jié)點(diǎn)，記N=successor（k），圖中關(guān)鍵字4 的標(biāo)識(shí)符小于節(jié)點(diǎn)6 標(biāo)識(shí)符，且節(jié)點(diǎn)6 位關(guān)鍵字4 后的第一個(gè)節(jié)點(diǎn)，滿足6=successor（4）。這種查詢方式的復(fù)雜度為O（n），n 是節(jié)點(diǎn)個(gè)數(shù)，當(dāng)系統(tǒng)規(guī)模越大時(shí)，查詢效率越低。

為了加快節(jié)點(diǎn)的查詢效率，改進(jìn)型Chord 采用指針表（finger table）的查詢方式，每個(gè)節(jié)點(diǎn)維護(hù)一個(gè)包含若干項(xiàng)記錄的指針表，項(xiàng)數(shù)由標(biāo)識(shí)符的位數(shù)m 所決定，環(huán)中最大節(jié)點(diǎn)標(biāo)識(shí)符NID 需滿足式（1）：

圖2 Chord環(huán)

并且節(jié)點(diǎn)N 在指針表中的第i 個(gè)表項(xiàng)節(jié)點(diǎn)S，滿足式（2）：

其中，s 和n 分別是節(jié)點(diǎn)S 和N 的標(biāo)識(shí)符。圖3 是節(jié)點(diǎn)10 的指針表，因?yàn)?8＜26，所以m 為6。對(duì)于指定的關(guān)鍵字，Chord 先判斷關(guān)鍵字是否落在對(duì)應(yīng)的節(jié)點(diǎn)中，是則結(jié)束查詢，否則節(jié)點(diǎn)將查詢請(qǐng)求發(fā)送到指針表中距離關(guān)鍵字最近的節(jié)點(diǎn)，重復(fù)該過(guò)程，直到找到指定節(jié)點(diǎn)。

圖3 節(jié)點(diǎn)10指針表

這種查詢方式每次都以2 的冪指數(shù)為間隔，所以每次減少整個(gè)環(huán)的一半容量，對(duì)于一個(gè)包含N 個(gè)節(jié)點(diǎn)的網(wǎng)絡(luò)來(lái)說(shuō)，這種關(guān)鍵字查詢方式的時(shí)間復(fù)雜度為O（logN）[17]。

1.2 系統(tǒng)架構(gòu)設(shè)計(jì)

本文結(jié)合了改進(jìn)型Chord 路由算法，提出了一種新的解決方案。首先，建立改進(jìn)型Chord 環(huán)，將集群中各服務(wù)器節(jié)點(diǎn)分布到Chord 環(huán)上；其次，建立路由信息表，在集群中加入一個(gè)路由器節(jié)點(diǎn)，保存所有服務(wù)器節(jié)點(diǎn)的路由信息，同時(shí)各節(jié)點(diǎn)建立一個(gè)路由表，用于節(jié)點(diǎn)間的快速查找，最后，再設(shè)計(jì)一套集群軟件管理策略，用于維護(hù)節(jié)點(diǎn)的加入和退出。

本文方案系統(tǒng)組成結(jié)構(gòu)如圖4 所示。系統(tǒng)各個(gè)部分功能模塊圖如圖5 所示，路由器節(jié)點(diǎn)包含預(yù)取模塊，能減少對(duì)講機(jī)客戶端向服務(wù)器發(fā)起請(qǐng)求的次數(shù)，以減輕集群壓力；服務(wù)器節(jié)點(diǎn)包含節(jié)點(diǎn)加入、退出和線程池模塊，分別用于處理新節(jié)點(diǎn)加入、已有節(jié)點(diǎn)退出和對(duì)講數(shù)據(jù)轉(zhuǎn)發(fā)等任務(wù)，同時(shí)需要和路由器時(shí)刻保持連接；網(wǎng)絡(luò)對(duì)講機(jī)是發(fā)起數(shù)據(jù)轉(zhuǎn)發(fā)請(qǐng)求或接收服務(wù)器節(jié)點(diǎn)轉(zhuǎn)發(fā)的數(shù)據(jù)的客戶端，進(jìn)行網(wǎng)絡(luò)對(duì)講前，先向路由器預(yù)取服務(wù)器節(jié)點(diǎn)信息，然后直接向服務(wù)器節(jié)點(diǎn)發(fā)起對(duì)講轉(zhuǎn)發(fā)請(qǐng)求，并等待節(jié)點(diǎn)轉(zhuǎn)發(fā)對(duì)講語(yǔ)音數(shù)據(jù)，如果該節(jié)點(diǎn)出現(xiàn)了問(wèn)題，則根據(jù)相關(guān)的軟件策略自動(dòng)選擇其后繼節(jié)點(diǎn)進(jìn)行服務(wù)。服務(wù)器端和客戶端程序執(zhí)行的流程圖如圖6、7 所示。

圖4 系統(tǒng)結(jié)構(gòu)圖

圖5 各部分功能模塊圖

圖6 服務(wù)器端軟件流程

1.3 軟件管理策略

（1）路由維護(hù)策略

用戶維護(hù)和緩存各服務(wù)器節(jié)點(diǎn)的路由信息。如果在M 個(gè)周期內(nèi)沒(méi)有收到節(jié)點(diǎn)的心跳信息，則標(biāo)記當(dāng)前節(jié)點(diǎn)處于靜默期，在N（N＞M）個(gè)周期依舊沒(méi)有收到節(jié)點(diǎn)的心跳信息，則從緩存中刪除該節(jié)點(diǎn)的信息，并通知集群中其他的服務(wù)器節(jié)點(diǎn)更新路由表，而各節(jié)點(diǎn)只維護(hù)其后繼節(jié)點(diǎn)路由信息，如果節(jié)點(diǎn)加入和退出的時(shí)間剛發(fā)生在客戶端發(fā)起請(qǐng)求的時(shí)間段，通過(guò)路由器獲取到的節(jié)點(diǎn)路由信息會(huì)導(dǎo)致無(wú)法找到節(jié)點(diǎn)，此時(shí)，客戶端在本地查找該節(jié)點(diǎn)的后繼節(jié)點(diǎn)，并發(fā)起通信請(qǐng)求，通過(guò)在節(jié)點(diǎn)上做二層路由維護(hù)，可以保證客戶端和節(jié)點(diǎn)的通信安全。

圖7 客戶端軟件流程

（2）節(jié)點(diǎn)加入策略

步驟1：節(jié)點(diǎn)加入到集群前，先向路由器進(jìn)行路由信息注冊(cè)；

步驟2：路由器接收到節(jié)點(diǎn)加入的請(qǐng)求后，緩存新加入節(jié)點(diǎn)的路由信息到路由表中，然后通知集群中其他節(jié)點(diǎn)更新路由表，其他節(jié)點(diǎn)按照式（4）更新本節(jié)點(diǎn)的路由信息表；

步驟3：新加入節(jié)點(diǎn)同樣根據(jù)式（4）建立本節(jié)點(diǎn)的路由信息表，并將路由信息表緩存到內(nèi)存中；

步驟4：當(dāng)客戶端向路由器發(fā)起預(yù)取路由信息請(qǐng)求時(shí)，路由器節(jié)點(diǎn)通知客戶端有新節(jié)點(diǎn)加入，并返回更新后所有節(jié)點(diǎn)的路由信息；

步驟5：客戶端更新本地緩存中的服務(wù)器節(jié)點(diǎn)路由信息表。

（3）節(jié)點(diǎn)退出策略

步驟1：節(jié)點(diǎn)退出時(shí)，路由器通知其他節(jié)點(diǎn)更新路由信息表；

步驟2：節(jié)點(diǎn)根據(jù)式（4）判定當(dāng)前退出的節(jié)點(diǎn)是否屬于其路由表中節(jié)點(diǎn)，如果屬于則將緩存中該節(jié)點(diǎn)的路由信息移除；

步驟3：當(dāng)客戶端向路由器發(fā)起預(yù)取路由信息請(qǐng)求時(shí)，路由器節(jié)點(diǎn)通知客戶端有節(jié)點(diǎn)退出，并返回更新后所有節(jié)點(diǎn)的路由信息；

步驟4：客戶端更新本地緩存中的服務(wù)器節(jié)點(diǎn)路由信息表。

（4）客戶端請(qǐng)求策略

客戶端先向中心路由器節(jié)點(diǎn)預(yù)取其所維護(hù)的服務(wù)器集群的路由信息并在內(nèi)存中保存；當(dāng)客戶端發(fā)起數(shù)據(jù)請(qǐng)求時(shí)，首先通過(guò)哈希函數(shù)SHA-1 求出客戶端請(qǐng)求數(shù)據(jù)的哈希值V，計(jì)算方式為式（3）：

然后檢查其路由表緩存信息中是否能找到相應(yīng)的節(jié)點(diǎn)，如果存在對(duì)應(yīng)的服務(wù)器節(jié)點(diǎn)則直接向該服務(wù)器節(jié)點(diǎn)發(fā)起通信請(qǐng)求并由其轉(zhuǎn)發(fā)對(duì)講語(yǔ)音數(shù)據(jù)，否則先向該服務(wù)器節(jié)點(diǎn)發(fā)起路由轉(zhuǎn)發(fā)請(qǐng)求，由該服務(wù)器節(jié)點(diǎn)在其路由信息表中查找目標(biāo)節(jié)點(diǎn)，如果目標(biāo)節(jié)點(diǎn)不在當(dāng)前節(jié)點(diǎn)的路由信息表中，則該節(jié)點(diǎn)繼續(xù)向其后繼節(jié)點(diǎn)轉(zhuǎn)發(fā)請(qǐng)求，直到找到目標(biāo)節(jié)點(diǎn)。

2 實(shí)驗(yàn)結(jié)果與分析

為了分析本文所提出方案的性能，設(shè)計(jì)了如下實(shí)驗(yàn)方案。實(shí)驗(yàn)環(huán)境參數(shù)如表1 所示，實(shí)驗(yàn)中所用到的集群是采用線程方式來(lái)模擬的，包括有1 個(gè)路由器節(jié)點(diǎn)和6個(gè)對(duì)講語(yǔ)音服務(wù)器節(jié)點(diǎn)，對(duì)講機(jī)客戶端使用進(jìn)程模擬，一個(gè)客戶端對(duì)應(yīng)一個(gè)進(jìn)程。主機(jī)使用TP-Link 路由器提供局域網(wǎng)網(wǎng)絡(luò)，路由器節(jié)點(diǎn)、對(duì)講語(yǔ)音服務(wù)器節(jié)點(diǎn)和對(duì)講機(jī)客戶端軟件均是采用Java 語(yǔ)言進(jìn)行編寫(xiě)的。

表1 測(cè)試環(huán)境

實(shí)驗(yàn)的客戶端個(gè)數(shù)和每個(gè)客戶端所發(fā)送的文件大小對(duì)應(yīng)關(guān)系表如表2 所示。實(shí)驗(yàn)測(cè)試結(jié)果均采取計(jì)10次并發(fā)訪問(wèn)的響應(yīng)時(shí)間和數(shù)據(jù)讀寫(xiě)時(shí)間總和求平均值的方式，按以下6 種情況進(jìn)行對(duì)比。

表2 實(shí)驗(yàn)測(cè)試情況表

（1）Chord 預(yù)?。杭菏褂肅hord 路由算法維護(hù)各對(duì)講語(yǔ)音服務(wù)器節(jié)點(diǎn)，且路由器節(jié)點(diǎn)提供預(yù)取機(jī)制。客戶端在空閑時(shí)向路由器預(yù)取各服務(wù)器節(jié)點(diǎn)路由表信息，當(dāng)客戶端發(fā)起數(shù)據(jù)讀寫(xiě)請(qǐng)求時(shí)，直接到內(nèi)存中找到其對(duì)應(yīng)的目標(biāo)節(jié)點(diǎn)，然后向目標(biāo)節(jié)點(diǎn)發(fā)起數(shù)據(jù)通信連接，各服務(wù)器節(jié)點(diǎn)使用線程池技術(shù)同客戶端通信。

（2）無(wú)Chord 預(yù)?。杭翰皇褂肅hord 算法維護(hù)各對(duì)講語(yǔ)音服務(wù)器節(jié)點(diǎn)，各節(jié)點(diǎn)使用線程池方式和對(duì)講機(jī)客戶端通信，但路由器節(jié)點(diǎn)提供預(yù)取機(jī)制。

從圖8 可以看出，無(wú)Chord 預(yù)取和Chord 預(yù)取響應(yīng)時(shí)間基本保持一致，這是由于對(duì)于客戶端而言，都只和路由節(jié)點(diǎn)發(fā)起一次通信請(qǐng)求，不能體現(xiàn)Chord 算法在維護(hù)服務(wù)器集群路由表信息的優(yōu)勢(shì)。

（3）Chord 無(wú)預(yù)?。杭菏褂肅hord 路由算法維護(hù)各個(gè)對(duì)講語(yǔ)音服務(wù)器節(jié)點(diǎn)，但路由器節(jié)點(diǎn)不向客戶端提供預(yù)取機(jī)制?？蛻舳嗣看蜗蚰繕?biāo)節(jié)點(diǎn)發(fā)起數(shù)據(jù)讀寫(xiě)請(qǐng)求時(shí)，都要先向路由器獲取目標(biāo)節(jié)點(diǎn)的路由表信息，然后客戶端向目標(biāo)節(jié)點(diǎn)發(fā)起數(shù)據(jù)通信連接。

圖8 Chord預(yù)取與無(wú)Chord預(yù)取時(shí)間對(duì)比圖

（4）無(wú)Chord 無(wú)預(yù)?。杭翰皇褂肅hord 算法維護(hù)各對(duì)講語(yǔ)音服務(wù)器節(jié)點(diǎn)，各對(duì)講語(yǔ)音服務(wù)器節(jié)點(diǎn)使用線程池方式和對(duì)講機(jī)客戶端通信，路由器也不提供預(yù)取機(jī)制。

從圖9 可以看出，無(wú)Chord 無(wú)預(yù)取和Chord 無(wú)預(yù)取響應(yīng)時(shí)間也基本保持一致，這是由于對(duì)于客戶端而言，每次進(jìn)行數(shù)據(jù)讀寫(xiě)時(shí)都要向路由器節(jié)點(diǎn)發(fā)起一次通信請(qǐng)求，同樣不能體現(xiàn)Chord 算法在維護(hù)服務(wù)器集群路由表信息的優(yōu)勢(shì)。

圖9 Chord無(wú)預(yù)取與無(wú)Chord無(wú)預(yù)取時(shí)間對(duì)比圖

（5）指針表跳轉(zhuǎn)：當(dāng)目標(biāo)節(jié)點(diǎn)不在客戶端緩存的路由表中時(shí)，客戶端會(huì)向根據(jù)標(biāo)識(shí)符值向指定服務(wù)器節(jié)點(diǎn)發(fā)起請(qǐng)求，再由該節(jié)點(diǎn)去找到目標(biāo)節(jié)點(diǎn)。而使用線程池技術(shù)時(shí)，客戶端會(huì)向路由器發(fā)起多次連接，直到路由器找到了和該客戶端通信的節(jié)點(diǎn)。從圖10 可以看出，使用Chord 管理方案比使用線程池技術(shù)的時(shí)間更少，響應(yīng)更快。

圖10 指針表跳轉(zhuǎn)對(duì)比圖

（6）路由器節(jié)點(diǎn)是否提供預(yù)?。簩?shí)驗(yàn)用于對(duì)比預(yù)取機(jī)制是否可以加快集群的響應(yīng)速度。如果路由器節(jié)點(diǎn)向?qū)χv機(jī)客戶端提供預(yù)取機(jī)制，則客戶端在空閑的時(shí)候向路由器節(jié)點(diǎn)預(yù)取各對(duì)講語(yǔ)音服務(wù)器節(jié)點(diǎn)路由信息，否則，客戶端每次發(fā)起數(shù)據(jù)讀寫(xiě)請(qǐng)求時(shí)都會(huì)向路由器節(jié)點(diǎn)發(fā)起請(qǐng)求，獲取對(duì)應(yīng)的對(duì)講語(yǔ)音節(jié)點(diǎn)路由，然后向該節(jié)點(diǎn)發(fā)起數(shù)據(jù)讀寫(xiě)操作。

從圖11 可知，有預(yù)取比無(wú)預(yù)取的集群響應(yīng)速度更快，這是因?yàn)橛蓄A(yù)取機(jī)制時(shí)，對(duì)講機(jī)客戶端不需要花費(fèi)時(shí)間和路由器節(jié)點(diǎn)建立連接。

從以上6 個(gè)實(shí)驗(yàn)可以，集群使用Chord 算法維護(hù)集群各節(jié)點(diǎn)，集群并發(fā)訪問(wèn)的響應(yīng)時(shí)間分別為使用線程池方式維護(hù)時(shí)的63.60%、65.60%、64.70%。

3 結(jié)語(yǔ)

網(wǎng)絡(luò)對(duì)講機(jī)的廣泛使用，使得服務(wù)器面臨了大量網(wǎng)絡(luò)對(duì)講機(jī)請(qǐng)求時(shí)的高并發(fā)處理問(wèn)題。本文介紹了目前用于高并發(fā)處理的多線程和多進(jìn)程方案，并在此基礎(chǔ)上結(jié)合Chord 路由算法，設(shè)計(jì)了一套高并發(fā)處理方案，以提高集群的響應(yīng)速度，最后通過(guò)實(shí)驗(yàn)的方式，比較本文的方案和文中提到的其他方案在處理高并發(fā)訪問(wèn)時(shí)系統(tǒng)的響應(yīng)時(shí)間。從實(shí)驗(yàn)的結(jié)果可以看出，本文提出的高并發(fā)處理方案在并發(fā)處理效率和時(shí)間代價(jià)等方面相比其他方案更加優(yōu)越。

圖11 Chord預(yù)取和Chord無(wú)預(yù)取對(duì)比圖