專利名稱：基于io事件通知機(jī)制的單進(jìn)程內(nèi)容服務(wù)器裝置及方法
技術(shù)領(lǐng)域：
本發(fā)明涉及單進(jìn)程高性能內(nèi)容服務(wù)器的輸入輸出，特別涉及一種基于10事件通 知機(jī)制的單進(jìn)程高性能內(nèi)容服務(wù)器10裝置及方法。
背景技術(shù)：
內(nèi)容分發(fā)服務(wù)器主要存儲多媒體文檔，如圖形圖像，媒體文件等。 一個服務(wù)器在工作時通常會面對互聯(lián)網(wǎng)上上萬的并發(fā)請求，因此對服務(wù)器的網(wǎng)絡(luò)IO(輸入輸出) 和磁盤IO性能要求都很高。常見的內(nèi)容服務(wù)器10 —般使用多進(jìn)程或多線程架構(gòu)。這樣做的主要原因是， 網(wǎng)絡(luò)IO和磁盤IO —般都是阻塞同步的， 一個進(jìn)程或線程執(zhí)行一個連接上的IO操作時，整個進(jìn)程或線程就被阻塞，無法同時處理其他連接，如果使用多個進(jìn)程或線程，每個進(jìn)程或線程對應(yīng)一個連接，就可以實現(xiàn)并發(fā)處理，充分利用CPU資源。附圖1說明了多進(jìn)程和多線程服務(wù)器的一般架構(gòu)方式。服務(wù)器在初始化階段預(yù) 先創(chuàng)建多個進(jìn)程或線程，形成進(jìn)程池或線程池，其中一個進(jìn)程或線程是主控進(jìn)程或 主控線程，其他進(jìn)程或線程為工作進(jìn)程或工作線程。主控進(jìn)程或主控線程負(fù)責(zé)接收 網(wǎng)絡(luò)上到達(dá)的客戶請求，并將請求分配給進(jìn)程池或線程池中的工作進(jìn)程或工作線程 處理。工作進(jìn)程或工作線程處理完畢后等待下一次主控進(jìn)程或主控線程的調(diào)配。這種服務(wù)器的代表是Apache,它是目前最流行的Web內(nèi)容服務(wù)器，可以在多進(jìn)程和 多線程兩種模式下運(yùn)行。多進(jìn)程服務(wù)器可以避免不斷創(chuàng)建進(jìn)程所帶來的系統(tǒng)開銷。但由于處理請求時它 用一個進(jìn)程來處理一個請求，如果要使服務(wù)器能夠處理較高的負(fù)載，就必須加大預(yù) 先創(chuàng)建的進(jìn)程數(shù)，而預(yù)先創(chuàng)建進(jìn)程數(shù)的上限會受到系統(tǒng)的限制，且進(jìn)程間切換的開 銷比較大。另外，在多進(jìn)程服務(wù)器中，進(jìn)程間的通信和資源共享也很困難。多線程服務(wù)器的優(yōu)勢體現(xiàn)在 一個進(jìn)程的多個線程在同一進(jìn)程的地址空間中， 容易實現(xiàn)線程間的數(shù)據(jù)共享；在工作時，創(chuàng)建一個線程比創(chuàng)建一個進(jìn)程的開銷要小; 線程的上下文切換發(fā)生在同一個進(jìn)程內(nèi)，所花費(fèi)的開銷比進(jìn)程間切換的開銷要少。 與多進(jìn)程服務(wù)器相比，由于多線程服務(wù)器消耗的資源要少，因此多線程服務(wù)器的擴(kuò) 展性要高很多。然而，由于在很多操作系統(tǒng)中，比較多數(shù)量的用戶級線程復(fù)用了較少數(shù)量的內(nèi)核執(zhí)行體。當(dāng)一個用戶級線程調(diào)用了一個阻塞的系統(tǒng)調(diào)用，它對應(yīng)的內(nèi) 核執(zhí)行體也會被阻塞，會導(dǎo)致復(fù)用同一個執(zhí)行體的其他用戶級線程也阻塞，影響了 系統(tǒng)性能，多線程的服務(wù)器的擴(kuò)展性受到了限制。由上述說明可見，多進(jìn)程和多線程服務(wù)器都存在不同程度的缺點(diǎn)。于是操作系 統(tǒng)提供了一種IO事件通知機(jī)制使得在一個線程之內(nèi)可以并發(fā)處理多個網(wǎng)絡(luò)10請 求。應(yīng)用程序可以通過這種機(jī)制同時監(jiān)聽多個網(wǎng)絡(luò)套接字，當(dāng)某個套接字上有10事件發(fā)生時，比如有新數(shù)據(jù)到達(dá)，這個套接字就有可讀事件，這個事件及其相關(guān)信息可以通過一個系統(tǒng)調(diào)用返回到用戶空間。結(jié)合非阻塞的網(wǎng)絡(luò)IO，這個機(jī)制就能在 單個進(jìn)程或線程內(nèi)完成并發(fā)處理。附圖2說明了這種機(jī)制的使用流程。 Linux/Unix/Windows中的select和poll系統(tǒng)調(diào)用、Linux中的epoll系統(tǒng)調(diào)用、FreeBSD 中的kqueue系統(tǒng)調(diào)用都是10事件通知機(jī)制。Lighttpd是單線程Web內(nèi)容服務(wù)器的 代表，其性能高于Apache。由于沒有了進(jìn)程和線程的維護(hù)開銷，基于IO事件通知機(jī)制的單線程服務(wù)器克 服了前面所述的多進(jìn)程和多線程服務(wù)器的缺點(diǎn)，可以達(dá)到很高的擴(kuò)展性。但是，這 種10事件通知機(jī)制一般只能處理網(wǎng)絡(luò)套接字的事件，不適用于磁盤文件描述符。 而目前的服務(wù)器所服務(wù)的內(nèi)容越來越大，無法存放在內(nèi)存中，因此大量的磁盤10 在服務(wù)器中是不可避免的。但是當(dāng)前操作系統(tǒng)中的磁盤10 —般都是同步阻塞的， 所以單線程的服務(wù)器會因為磁盤10而阻塞，服務(wù)器無法處理其他請求，使得服務(wù) 器的性能下降。發(fā)明內(nèi)容本發(fā)明的目的是克服單線程的服務(wù)器會因為磁盤10而阻塞，服務(wù)器無法處理 其他請求，使得服務(wù)器性能下降的缺陷，從而提供一種單進(jìn)程高性能內(nèi)容服務(wù)器的 IO裝置。為了實現(xiàn)上述目的，本發(fā)明提供了 一種基于10事件通知機(jī)制的單進(jìn)程高性能內(nèi) 容服務(wù)器IO裝置，包括請求隊列，還包括前臺線程、后臺線程池和IO事件通知機(jī) 制；其中，所述的前臺線程與所述的請求隊列、IO事件通知機(jī)制相連，所述的請求 隊列和所述的10事件通知機(jī)制還連接到所述的后臺線程池上，所述的前臺線程還 與外部的客戶端連接。上述技術(shù)方案中，所述的前臺線程是一個單一的線程，所述的前臺線程負(fù)責(zé)接 受外部客戶端發(fā)來的新的網(wǎng)絡(luò)連接，還負(fù)責(zé)發(fā)送和接收網(wǎng)絡(luò)協(xié)議數(shù)據(jù)。上述技術(shù)方案中，所述的后臺線程池包括一個以上的工作線程，所述工作線程用于處理磁盤的IO操作。上述技術(shù)方案中，所述的IO事件通知機(jī)制采用Linux中的epoll系統(tǒng)調(diào)用。 本發(fā)明還提供了一種在所述的基于10事件通知機(jī)制的單進(jìn)程高性能內(nèi)容服務(wù) 器I0裝置中實現(xiàn)IO請求處理的方法，包括以下步驟步驟10)、所述前臺線程等待外部客戶端發(fā)來的10事件通知； 步驟20)、所述前臺線程讀取客戶端發(fā)來的IO請求，并解析該請求； 步驟30)、所述前臺線程將解析后的請求放入所述的請求隊列中； 步驟40)、所述請求隊列中的新請求喚醒所述后臺線程池中的一個空閑的工作 線程，該工作線程根據(jù)請求的10信息同步和阻塞地執(zhí)行磁盤10操作；步驟50)、磁盤IO操作完成后，把操作結(jié)果寫到一個管道中，所述的IO事件 通知機(jī)制得到管道可讀事件，并通知所述的前臺線程；步驟60)、所述的前臺線程得到最終的結(jié)果，并將結(jié)果返回給客戶端。 本發(fā)明結(jié)合了 IO事件通知機(jī)制對于網(wǎng)絡(luò)IO的處理優(yōu)勢和多線程對于同步阻塞 的磁盤IO處理優(yōu)勢，有效地解決了內(nèi)容服務(wù)器中高密集的網(wǎng)絡(luò)10和磁盤10性能 問題。較之背景技術(shù)中介紹的服務(wù)器架構(gòu)，不僅減少了上下文切換和進(jìn)程間通信和 共享資源的開銷，而且消除了創(chuàng)建線程的開銷，并做到了線程數(shù)和連接數(shù)無關(guān)，從 而可以達(dá)到高并發(fā)和高擴(kuò)展性，滿足大規(guī)模用戶數(shù)的內(nèi)容分發(fā)服務(wù)。


圖1是現(xiàn)有技術(shù)中多進(jìn)程和多線程的服務(wù)器的工作流程圖； 圖2是現(xiàn)有技術(shù)中基于10事件通知機(jī)制的單線程服務(wù)器的工作流程圖； 圖3是本發(fā)明的基于10事件通知機(jī)制的單進(jìn)程高性能內(nèi)容服務(wù)器IO裝置的結(jié) 構(gòu)圖；圖4是本發(fā)明中IO請求處理方法的流程圖；圖5是實施例邊緣服務(wù)器的主控模塊控制流程圖；圖6是邊緣服務(wù)器中所采用的epoll機(jī)制的循環(huán)控制流圖。
具體實施方式
下面結(jié)合附圖和具體實施方式
對本發(fā)明作進(jìn)一步詳細(xì)描述-如圖3所示，本發(fā)明的單進(jìn)程髙性能內(nèi)容服務(wù)器的輸入輸出部分包括前臺線 程302、請求隊列303、后臺線程池304和IO事件通知機(jī)制305;其中，前臺線程 302與請求隊列303、 10事件通知機(jī)制305相連，請求隊列303和10事件通知機(jī)制305還連接到后臺線程池304上。前臺線程302是一個單一的線程，該線程主要用于處理網(wǎng)絡(luò)10，在具體實現(xiàn)時， 前臺線程不僅要負(fù)責(zé)接受新的網(wǎng)絡(luò)連接，也要負(fù)責(zé)發(fā)送和接收網(wǎng)絡(luò)協(xié)議數(shù)據(jù)。與背 景技術(shù)中提到的多線程服務(wù)器相比，多線程服務(wù)器中的主控進(jìn)程僅用于接收新的網(wǎng) 絡(luò)連接，并不對網(wǎng)絡(luò)數(shù)據(jù)進(jìn)行處理，這與前臺線程302有著明顯的區(qū)別。后臺線程池304中有多個工作線程，后臺線程池304用于處理磁盤10。在前臺線程302中，網(wǎng)絡(luò)10都被設(shè)置為非阻塞狀態(tài)，所有的連接都在一個線 程中被處理。操作系統(tǒng)提供10事件通知方式305來告訴應(yīng)用程序有哪些連接在什 么時刻要求服務(wù)。為此，應(yīng)用程序必須向操作系統(tǒng)聲明一組自己感興趣的網(wǎng)絡(luò)套接 字。操作系統(tǒng)將負(fù)責(zé)監(jiān)視這些套接字， 一旦有與套接字中的描述符相對應(yīng)的網(wǎng)絡(luò)連 接有讀或?qū)懯录l(fā)生。內(nèi)核便會以事件的方式通知應(yīng)用程序。依賴于這種事件通知 機(jī)制，操作系統(tǒng)向應(yīng)用層提供一組描述符所對應(yīng)的事件的通知，進(jìn)而支持所有的連 接在單個線程中被處理。在前述的說明中己經(jīng)提到，在本實施例中，所述的10事 件通知機(jī)制305采用Linux中的epoll系統(tǒng)調(diào)用。Epoll系統(tǒng)調(diào)用較之過去的select 和poll,只返回有事件到達(dá)的描述符，這樣就省去了遍歷所有描述符來探測是否就 緒的開銷。在互聯(lián)網(wǎng)環(huán)境中，面對大量質(zhì)量不高的連接并發(fā)的情況下，可以提高性 能。和實時信號相比，epoll也沒有信號溢出的問題，適合于高并發(fā)的環(huán)境。請求隊列303是一個與后臺線程共享的隊列，請求隊列303從前臺線程302中 接收外界的請求并存儲，供后臺線程池做后續(xù)操作。在上述實現(xiàn)的基礎(chǔ)上，本發(fā)明還提供了一種處理IO請求的方法，如圖4所示，包含以下步驟步驟10、前臺線程302等待客戶端發(fā)來的10事件通知；步驟20、前臺線程302讀取客戶端發(fā)來的請求，并解析該請求；步驟30、前臺線程302將解析后的請求放入請求隊列303中；步驟40、請求隊列303中的新請求喚醒后臺線程池304中的某一個工作線程，該工作線程根據(jù)請求的IO信息同步和阻塞地執(zhí)行磁盤10操作；步驟50、步驟40中的操作完成后，把操作結(jié)果寫到管道310中，IO事件通知機(jī)制305得到管道可讀事件，并通知前臺線程302;步驟60、前臺線程302得到最終的結(jié)果，并將結(jié)果寫到網(wǎng)絡(luò)套接字，返回給客戶端。在上述方法中，前臺線程302在把磁盤10請求放入請求隊列303后就不需要阻塞地等待磁盤IO的完成，可以繼續(xù)處理其他的網(wǎng)絡(luò)IO。當(dāng)磁盤IO完成后又可以 通過10事件通知機(jī)制及時獲得結(jié)果。在一個實施例中，以邊緣服務(wù)器(ESP， Edge Service Provider)為例，對本發(fā)明作 詳細(xì)的說明。該邊緣服務(wù)器運(yùn)行在Linux操作系統(tǒng)上，采用Linux 2.6版本內(nèi)核中的 epoll作為10事件通知機(jī)制。ESP主要分為以下幾個模塊主控模塊系統(tǒng)的主線程，負(fù)責(zé)調(diào)度其他模塊。其中負(fù)責(zé)前臺監(jiān)聽事件的是 EpollEventScheduler類，它負(fù)責(zé)EpollEvent事件的調(diào)度。ContentRouter協(xié)議處理模塊處理與ContentRouter的交互。ContenRouter是用 在內(nèi)容分發(fā)系統(tǒng)協(xié)調(diào)ESP工作的模塊。下載協(xié)議處理模塊當(dāng)用戶需要從系統(tǒng)下載時，處理與用戶的交互。CMiddleServer模塊接受請求，將請求交由PPIO模塊處理，從PPIO模塊獲 得處理完的請求后再返回給提出請求的模塊。PPIO模塊:底層文件系統(tǒng)負(fù)責(zé)實際的文件讀寫操作。即后臺多線程處理磁盤I0。下面分別對上述模塊的具體實現(xiàn)進(jìn)行說明-A) 、主控模塊主控模塊是由CEspServer類實現(xiàn)，主要的類接口函數(shù)是CEspServer::Run()，采 用EPOLL調(diào)度方式，當(dāng)有套接字有事件到達(dá)時，調(diào)用套接字所對應(yīng)對象的套接字 處理函數(shù)進(jìn)行處理，當(dāng)套接字可寫，會調(diào)用套接字所屬對象的SendData()函數(shù)將輸 出緩沖區(qū)的數(shù)據(jù)向套接字寫，當(dāng)套接字可讀，會調(diào)用套接字所屬對象的RevDataO 函數(shù)從套接字接收數(shù)據(jù)到緩沖區(qū)，當(dāng)遍歷完所有有事件發(fā)生的套接字后，判斷 CCRAgent的輸出緩沖區(qū)是否有數(shù)據(jù)，如果有數(shù)據(jù)就往CCRAgent的套接字寫。然 后判斷aio—reqjen <MAXREQNUM,如果是則調(diào)用MiddleServer.WakeUpAgent()喚 醒上次iosart失敗的agent 。在CEspServer類中實現(xiàn)了一個超時處理機(jī)制鏈表—timeList(C++ STL List類型， 元素是一個二元組結(jié)構(gòu)〈CAgent對象地址，到期時間>)，每當(dāng)epoll返回時，會遍歷 這個鏈表，當(dāng)發(fā)現(xiàn)到期時間大于當(dāng)前時間時，則會調(diào)用CAgent (CBtAgent, CCPAgent)對象的超時處理函數(shù)。整個流程如附圖5所示。B) 、 EpollEventScheduler: Epoll調(diào)度模塊，負(fù)責(zé)處理epoll事件。 EpoUEventScheduler類負(fù)責(zé)EpollEvent事件的調(diào)度，主要的類接口函數(shù)有EpollEventScheduler::doEventO負(fù)責(zé)注冊EpollEvent, EpollEventSchedu!er::Run()采 用EPOLL調(diào)度方式，當(dāng)有EpollEvent有事件到達(dá)時，調(diào)用套接字所對應(yīng)對象EpollEventHandler處理套接字事件，如果是寫事件，調(diào)用Epol正ventHandler的 SendData()函數(shù)處理；如果是讀事件，調(diào)用EpollEventHandler的RevData()函數(shù)處 理，當(dāng)遍歷完所有有事件發(fā)生的套接字后調(diào)用Timer::Check()檢査是否有定時器事件 發(fā)生，然后調(diào)用MiddleServer::Check()處理未請求成功的ReqHandler對象。整個流 程如附圖6所示。 C)、 PPIO模塊PPIO類作為ESP系統(tǒng)的一個子模塊，其主要作用就是為上層MiddlerServer 提供快速，高效的文件讀寫，査詢，刪除的功能。它利用0++中面向?qū)ο蟮乃枷耄?將各種實現(xiàn)封裝起來，僅給用戶提供必要的接口。用戶通過接口實現(xiàn)對下層文件的 操作。在用戶層實現(xiàn)了異步10。本申請中的異步10主要框架是采用預(yù)先創(chuàng)建線程， 形成線程池。處理流程對于Relay Server 10請求，通過Epoll獲知有讀事件，我 們讀socket,形成請求的數(shù)據(jù)結(jié)構(gòu)，先把請求放入到請求隊列上去，線程池里面的 線程等待在條件鎖上，當(dāng)有請求到來的時候，線程池中的工作線程被喚醒，他們通 過互斥鎖到請求隊列上面取回請求，工作線程采用同步的read/write系統(tǒng)調(diào)用處理 10,工作線程做完10后通過一個管道向epoll發(fā)送一個數(shù)據(jù)結(jié)構(gòu)的指針地址，這個 數(shù)據(jù)結(jié)構(gòu)里面包括了讀回內(nèi)容的Buf，返回的狀態(tài)信息等，epoll收到通知后，調(diào)用 read操作，從管道中讀出數(shù)據(jù)結(jié)構(gòu)的指針地址，通過這個指針，獲取AIO完成后 的結(jié)果信息，比如讀請求的話，就獲取結(jié)果Buf里面的內(nèi)容，然后通過Socket把它 發(fā)送到Relay Server。根據(jù)我們的性能比較，這種方式比前面幾種實現(xiàn)性能都要高， 而且實現(xiàn)起來比較容易。所以我們對磁盤IO的處理主要采用這種方式。如果多個線程同時使用同一個文件描述符來進(jìn)行I/O操作，你會發(fā)現(xiàn)傳統(tǒng) 的UNIX I/O接口不安全。在非串行的I/0(即并發(fā))發(fā)生時會有問題。它使用lseek 系統(tǒng)調(diào)用來為后續(xù)的read和write函數(shù)設(shè)置文件偏移量。如果兩個或更多的線程使 用lseek來移動同一個文件描述符，就會發(fā)生沖突。為了避免沖突，使用新的pread和pwrite系統(tǒng)調(diào)用。這些調(diào)用效果類似于read和write,不同之處在于多了一個參數(shù)，文件偏移量。 用這個參數(shù)，你可以用不著用1seek(2)指定偏移量，多線程可以對同一個文件描述 符進(jìn)行安全的操作。因此在線程讀寫的時候，在我們程序里面盡量采用pread， pwrite 的方式代替?zhèn)鹘y(tǒng)的read, write,保證線程讀寫的安全，而開始的時候我們采用的方 式是用flock的方式先鎖定文件描述符，然后進(jìn)行I0操作，操作完成之后再解鎖。 用了 pread, pwrite之后就不用我們來加鎖了，因為lseek和讀寫的操作變成了一個原子操作，就不存在多個線程改變文件偏移量的而導(dǎo)致錯誤的擔(dān)心。ESP可以按照BitTorrent協(xié)議分發(fā)內(nèi)容，測試表明在三千以上并發(fā)用戶的隨機(jī) 磁盤訪問請求下，在普通入門級服務(wù)器上運(yùn)行的ESP只占用很低的CPU就可以充 分利用磁盤能力和網(wǎng)絡(luò)能力，到達(dá)lOMB/s以上的網(wǎng)絡(luò)吞吐率。上述實施例是以ESP說明的，本發(fā)明也同樣適用與其他類型的內(nèi)容服務(wù)器。 最后所應(yīng)說明的是，以上實施例僅用以說明本發(fā)明的技術(shù)方案而非限制。盡管 參照實施例對本發(fā)明進(jìn)行了詳細(xì)說明，本領(lǐng)域的普通技術(shù)人員應(yīng)當(dāng)理解，對本發(fā)明 的技術(shù)方案進(jìn)行修改或者等同替換，都不脫離本發(fā)明技術(shù)方案的精神和范圍，其均 應(yīng)涵蓋在本發(fā)明的權(quán)利要求范圍當(dāng)中。
權(quán)利要求
1. 一種基于IO事件通知機(jī)制的單進(jìn)程高性能內(nèi)容服務(wù)器IO裝置，包括請求隊列，其特征在于，還包括前臺線程、后臺線程池和IO事件通知機(jī)制；其中，所述的前臺線程與所述的請求隊列、IO事件通知機(jī)制相連，所述的請求隊列和所述的IO事件通知機(jī)制還連接到所述的后臺線程池上，所述的前臺線程還與外部的客戶端連接。
2、 根據(jù)權(quán)利要求1所述的基于IO事件通知機(jī)制的單進(jìn)程高性能內(nèi)容服務(wù)器10 裝置，其特征在于，所述的前臺線程是一個單一的線程，所述的前臺線程負(fù)責(zé)接受 外部客戶端發(fā)來的新的網(wǎng)絡(luò)連接，還負(fù)責(zé)發(fā)送和接收網(wǎng)絡(luò)協(xié)議數(shù)據(jù)。
3、 根據(jù)權(quán)利要求1所述的基于IO事件通知機(jī)制的單進(jìn)程高性能內(nèi)容服務(wù)器10 裝置，其特征在于，所述的后臺線程池包括一個以上的工作線程，所述工作線程用 于處理磁盤的IO操作。
4、 根據(jù)權(quán)利要求1所述的基于10事件通知機(jī)制的單進(jìn)程高性能內(nèi)容服務(wù)器10 裝置，其特征在于，所述的10事件通知機(jī)制采用Linux中的epoll系統(tǒng)調(diào)用。
5、 一種在權(quán)利要求1所述的基于10事件通知機(jī)制的單進(jìn)程高性能內(nèi)容服務(wù)器 IO裝置中實現(xiàn)IO請求處理的方法，包括以下步驟步驟IO)、所述前臺線程等待外部客戶端發(fā)來的IO事件通知；步驟20)、所述前臺線程讀取客戶端發(fā)來的IO請求，并解析該請求；步驟30)、所述前臺線程將解析后的請求放入所述的請求隊列中；步驟40)、所述請求隊列中的新請求喚醒所述后臺線程池中的一個空閑的工作線程，該工作線程根據(jù)請求的10信息同步和阻塞地執(zhí)行磁盤10操作；步驟50)、磁盤IO操作完成后，把操作結(jié)果寫到一個管道中，所述的IO事件通知機(jī)制得到管道可讀事件，并通知所述的前臺線程；步驟60)、所述的前臺線程得到最終的結(jié)果，并將結(jié)果返回給客戶端。
全文摘要
本發(fā)明公開了一種基于IO事件通知機(jī)制的單進(jìn)程高性能內(nèi)容服務(wù)器IO裝置，包括請求隊列，還包括前臺線程、后臺線程池和IO事件通知機(jī)制；其中，所述的前臺線程與所述的請求隊列、IO事件通知機(jī)制相連，所述的請求隊列和所述的IO事件通知機(jī)制還連接到所述的后臺線程池上，所述的前臺線程還與外部的客戶端連接。本發(fā)明還公開了一種實現(xiàn)IO請求處理的方法。本發(fā)明不僅減少了上下文切換和進(jìn)程間通信和共享資源的開銷，而且消除了創(chuàng)建線程的開銷，并做到了線程數(shù)和連接數(shù)無關(guān)，從而可以達(dá)到高并發(fā)和高擴(kuò)展性，滿足大規(guī)模用戶數(shù)的內(nèi)容分發(fā)服務(wù)。
文檔編號G06F9/46GK101256505SQ20071006415
公開日2008年9月3日 申請日期2007年3月2日 優(yōu)先權(quán)日2007年3月2日
發(fā)明者旭 周, 暉 唐, 鼎 唐, 濤 林, 譚紅艷, 趙志軍 申請人:中國科學(xué)院聲學(xué)研究所