• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            sherrylso

            C++博客 首頁 新隨筆 聯(lián)系 聚合 管理
              18 Posts :: 0 Stories :: 124 Comments :: 0 Trackbacks

            一般來說,網(wǎng)絡(luò)應(yīng)用系統(tǒng)服務(wù)器的實(shí)現(xiàn),我們從設(shè)計(jì)模式的角度看,有兩種設(shè)計(jì)方案可供選擇:
            Reactor服務(wù)器,或者Proactor服務(wù)器。無論是Reactor,或者Proactor, 都是基于事件驅(qū)動(dòng)的架構(gòu)設(shè)計(jì)(Event-driven architecture), 它們的核心是思想是:分離網(wǎng)絡(luò)事件的監(jiān)視,驅(qū)動(dòng)與事物本身的邏輯處理。我們能看到的是:對(duì)任何的網(wǎng)絡(luò)應(yīng)用而言,其對(duì)網(wǎng)絡(luò)事件的監(jiān)視,處理往往是大同小異的,是可以分離出來作為可復(fù)用組件而存在的。
            對(duì)所有這些網(wǎng)絡(luò)應(yīng)用,所不用的是對(duì)網(wǎng)絡(luò)請(qǐng)求的邏輯處理。不同于Proactor, 或者Reactor,一般的設(shè)計(jì)方法是:
             

            而Proactor, 或者Reactor,設(shè)計(jì)的精髓是:


            別看這一點(diǎn)小小的變化,這是所謂的Hollywood Principle: 'Don't call us, we'll call you'。這是Framework設(shè)計(jì)者慣用的設(shè)計(jì)技巧,依賴倒轉(zhuǎn)(The Dependency-Inversion Principle):
            a. 高層模塊不應(yīng)該依賴于低層模塊,應(yīng)當(dāng)依賴于抽象。
            b. 抽象不應(yīng)該依賴于細(xì)節(jié),細(xì)節(jié)依賴于抽象。
            言歸正傳,我們來具體談?wù)凴eatctor and Proactor.
            一 、Reactor服務(wù)器實(shí)現(xiàn)。
            在Reactor的實(shí)現(xiàn)可分為兩層:
            a.Demultiplexing/Dispatching層:獨(dú)立于應(yīng)用邏輯層,捕獲,分發(fā)網(wǎng)絡(luò)請(qǐng)求給具體的網(wǎng)絡(luò)請(qǐng)求處理器。
            在這里注意的是,Demultiplexing和Dispatching是兩個(gè)不同的概念,Demultiplexing指的是網(wǎng)絡(luò)請(qǐng)求的偵聽,及其偵聽以后尋找適合的處理器。Dispatching指的是對(duì)處理器的回調(diào)。
            b.應(yīng)用邏輯層組件:主要處理與應(yīng)用相關(guān)的事物處理。
            其基本的結(jié)構(gòu)圖為


            其各個(gè)組成模塊的功能為:

            --〉句柄: 調(diào)用操作系統(tǒng)API獲得,用于identify事件源,如:網(wǎng)絡(luò)連接,打開的文件。
            --〉同步事件分離器:操作系統(tǒng)功能,通過API提供,典型的如: select調(diào)用,如windows平臺(tái)上的WaitForMultileObj
            --〉事件處理器:這是Demultiplexing/Dispatching層定義的抽象借口,是Demultiplexing/Dispatching層與應(yīng)用邏輯層之間的協(xié)議約定。應(yīng)用邏輯層依賴于該抽象借口。
            --〉具體事件處理器:事件處理器的具體實(shí)現(xiàn),一般來說,由應(yīng)用邏輯層組件實(shí)現(xiàn)。
            --〉Reactor:提供接口給應(yīng)用邏輯層,注冊(cè)或者反注冊(cè)事件處理器,運(yùn)行應(yīng)用的事件循環(huán)(反復(fù)調(diào)用同步事件分離器),驅(qū)動(dòng)Demultiplexing/Dispatching層。

            二 、Proactor服務(wù)器實(shí)現(xiàn)。
            在Proactor的實(shí)現(xiàn)也分為兩層:
            a.Demultiplexing/Dispatching層:獨(dú)立于應(yīng)用邏輯層,捕獲,分發(fā)網(wǎng)絡(luò)請(qǐng)求給具體的網(wǎng)絡(luò)請(qǐng)求處理器,不同于Reactor的是,這一層的策略處理
            基于異步操作,從實(shí)現(xiàn)的復(fù)雜度上,要復(fù)雜于Reactor。
            b.應(yīng)用邏輯層組件:主要處理與應(yīng)用相關(guān)的事物處理。
            Proactor基本的結(jié)構(gòu)圖為


            --〉句柄: 調(diào)用操作系統(tǒng)API獲得,用于identify事件源,如:網(wǎng)絡(luò)連接,打開的文件。與Reactor不同的是,由于Proactor操作是異步的,所以,與每一個(gè)異步IO操作項(xiàng)關(guān)聯(lián)的,有一個(gè)完成事件(Completion Event),當(dāng)一個(gè)異步的IO操作執(zhí)行完成后,一個(gè)操作系統(tǒng)的IO子系統(tǒng)會(huì)產(chǎn)生一個(gè)完成事件。
            --〉異步操作:一個(gè)異步操作可以是一個(gè)服務(wù)請(qǐng)求的具體實(shí)現(xiàn),如從連接的socket上讀入數(shù)據(jù),或者寫入數(shù)據(jù)到本地磁盤。異步操作的發(fā)起執(zhí)行,并不會(huì)由于慢速的IO而阻塞調(diào)用線程,調(diào)用線程在發(fā)起異步操作之后,可以去做別的事情。這是Proactor能增大服務(wù)器處理吞吐量的關(guān)鍵所在。我們付出的代價(jià)是,開發(fā)的復(fù)雜度要比Reactor。
            --〉完成 事件處理器:Demultiplexing/Dispatching層定義的抽象借口。由應(yīng)用邏輯層組件繼承來實(shí)現(xiàn)這些接口
            函數(shù)。
            --〉具體完成事件處理器:事件處理器的具體實(shí)現(xiàn)。
            --〉異步操作處理器:由native的操作系統(tǒng)實(shí)現(xiàn)。當(dāng)一個(gè)異步操作完成執(zhí)行時(shí),異步操作處理器會(huì)產(chǎn)生一個(gè)完成事件,然后把這個(gè)完成事件插入到完成事件隊(duì)列。
            --〉完成事件隊(duì)列:用于保存異步操作完成事件的隊(duì)列。在windows平臺(tái)上,就是我們所說的完成端口。
            --〉異步事件分離器: 操作系統(tǒng)功能,通過API提供。在windows平臺(tái)上,就是GetQueuedCompletionStatus()。異步事件分離器等待在完成事件隊(duì)列上,當(dāng)有完成事件被插入到完成事件隊(duì)列,異步事件分離器會(huì)從完成事件隊(duì)列取出該完成事件,返回給調(diào)用者。
            --〉Proactor:運(yùn)行應(yīng)用的事件循環(huán)(反復(fù)調(diào)用異步操作處理器),驅(qū)動(dòng)Demultiplexing/Dispatching層。
            --〉發(fā)起者:用于發(fā)起異步IO操作。
            三 、選擇?是Reactor,還是Proactor。
            在我們實(shí)現(xiàn)我們的服務(wù)器,是選擇Reactor,還是Proactor,個(gè)人認(rèn)為需要考慮的因素是:
            1)對(duì)于Reactor而言,好的地方是開發(fā)的復(fù)雜度小于Proactor,但缺點(diǎn)同樣明顯:
            第一,基于Reactor實(shí)現(xiàn)的服務(wù)器可擴(kuò)展性不如Proactor,這是由其本質(zhì)決定的。在wiondows平臺(tái)上,無論是
            Select,或者是WaitForMultiObj,其等待的最大handle數(shù)有一個(gè)最大的上限值(默認(rèn)值是64)。
            第二,基于Reactor實(shí)現(xiàn)的服務(wù)器服務(wù)請(qǐng)求處理的吞吐量不如Proactor好。特別是當(dāng)對(duì)客戶端的請(qǐng)求處理需要更長的時(shí)間時(shí),在Reactor的Demultiplexing/Dispatching層,由于Demultiplexing和Dispatching被順序化處理,這樣的話,很容易成為服務(wù)器性能的瓶頸。
            2)對(duì)于Proactor,如果你需要一個(gè)高性能的,高吞吐量的,并發(fā)服務(wù)器,Proactor絕對(duì)是首選的解決方案,它的問題主要在開發(fā)的難度比較大。
            不過,總的來說,我們可以看到,基于模式設(shè)計(jì)的Reactor和Proactor,都很好地把Application-Specific的處理邏輯從網(wǎng)絡(luò),IO事件的Demultiplexing/Dispatching中分離出來,對(duì)應(yīng)用程序而言,由于這樣的松耦合關(guān)系,我們的應(yīng)用完全可以在Reactor和Proactor中自由切換,而不需要修改任何的代碼。、
            四 、后記。
            ACE Framework,對(duì)Reactor和Proactor設(shè)計(jì)模式給出了經(jīng)典的實(shí)現(xiàn)。請(qǐng)參考:
            http://www.cs.wustl.edu/~schmidt/
            個(gè)人覺得是很好的學(xué)習(xí)材料。

            posted on 2007-06-10 20:19 愛上龍卷風(fēng) 閱讀(1052) 評(píng)論(1)  編輯 收藏 引用

            Feedback

            # re: 網(wǎng)絡(luò)應(yīng)用系統(tǒng)之服務(wù)器實(shí)現(xiàn) 2007-06-13 17:07 黃大仙
            好  回復(fù)  更多評(píng)論
              


            只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            久久免费99精品国产自在现线| 久久99久久99精品免视看动漫| 新狼窝色AV性久久久久久| 精品久久久久久无码中文字幕 | 久久无码中文字幕东京热| 国产精品一区二区久久精品无码| 国产精品一久久香蕉国产线看观看| 无码人妻久久一区二区三区| 亚洲国产精品久久电影欧美| 人妻精品久久无码区| 久久精品国产亚洲AV香蕉| 99国产精品久久久久久久成人热| 99久久精品影院老鸭窝| A级毛片无码久久精品免费| 久久精品国产一区| 久久国产成人午夜aⅴ影院| 久久伊人亚洲AV无码网站| 无码八A片人妻少妇久久| 色综合久久无码五十路人妻| 国产成人精品免费久久久久| 91麻豆精品国产91久久久久久| 久久精品亚洲男人的天堂| 亚洲一级Av无码毛片久久精品| 亚洲成色www久久网站夜月| 9久久9久久精品| 亚洲国产香蕉人人爽成AV片久久| 伊人久久综合成人网| 97久久精品人人做人人爽| 日本WV一本一道久久香蕉| 97久久精品无码一区二区天美 | 人妻无码久久一区二区三区免费| 国内精品久久久久影院日本| 激情综合色综合久久综合| 日韩人妻无码一区二区三区久久| 91久久香蕉国产熟女线看| 久久婷婷色综合一区二区| 青草影院天堂男人久久| 亚洲国产精品无码久久一区二区| 久久综合欧美成人| 国内精品人妻无码久久久影院 | 亚洲国产欧洲综合997久久|