Reactor與 Proactor

基本概念

在高性能的I/O設(shè)計中，有兩個比較著名的模式Reactor和Proactor模式，其中Reactor模式用于同步I/O，而Proactor運用于異步I/O操作。

????? ?在比較這兩個模式之前，我們首先的搞明白幾個概念，

• • 什么是阻塞和非阻塞

阻塞和非阻塞是針對于進程在訪問數(shù)據(jù)的時候，根據(jù)IO操作的就緒狀態(tài)來采取的不同方式，說白了是一種讀取或者寫入操作函數(shù)的實現(xiàn)方式。

阻塞方式下讀取或者寫入函數(shù)將一直等待。

非阻塞方式下，讀取或者寫入函數(shù)會立即返回一個狀態(tài)值。

• • 什么是同步和異步

同步和異步是針對應(yīng)用程序和內(nèi)核的交互而言的。

同步指的是用戶進程觸發(fā)IO操作并等待或者輪詢的去查看IO操作是否就緒。

異步是指用戶進程觸發(fā)IO操作以后便開始做自己的事情，而當(dāng)IO操作已經(jīng)完成的時候會得到IO完成的通知。

一般來說I/O模型可以分為：同步阻塞，同步非阻塞，異步阻塞，異步非阻塞。

讓我們來看一下每種不同I/O模型的具體描述

• • ???同步阻塞?IO：

???在此種方式下，用戶進程在發(fā)起一個IO操作以后，必須等待IO操作的完成，只有當(dāng)真正完成了IO操作以后，用戶進程才能運行。JAVA傳統(tǒng)的IO模型屬于此種方式！

• • ???同步非阻塞IO:

在此種方式下，用戶進程發(fā)起一個IO操作以后邊可返回做其它事情，但是用戶進程需要時不時的詢問IO操作是否就緒，這就要求用戶進程不停的去詢問，從而引入不必要的CPU資源浪費。其中目前JAVA的NIO就屬于同步非阻塞IO。

• • ???異步阻塞IO：

此種方式下,應(yīng)用發(fā)起一個IO操作以后，不等待內(nèi)核IO操作的完成，等內(nèi)核完成IO操作以后會通知應(yīng)用程序，這其實就是同步和異步最關(guān)鍵的區(qū)別，同步必須等待或者主動的去詢問IO是否完成，那么為什么說是阻塞的呢？因為此時是通過select系統(tǒng)調(diào)用來完成的，而select函數(shù)本身的實現(xiàn)方式是阻塞的，而采用select函數(shù)有個好處就是它可以同時監(jiān)聽多個文件句柄，從而提高系統(tǒng)的并發(fā)性！

• • ???異步非阻塞IO:

此種方式下，用戶進程只需要發(fā)起一個IO操作然后立即返回，等IO操作真正的完成以后，應(yīng)用程序會得到IO操作完成的通知，此時用戶進程只需要對數(shù)據(jù)進行處理就好了，不需要進行實際的IO讀寫操作，因為真正的IO讀取或者寫入操作已經(jīng)由內(nèi)核完成了。目前Java中還沒有支持此種IO模型。???

阻塞型I/O意味著控制權(quán)只有到調(diào)用操作結(jié)束后才會回到調(diào)用者手里.結(jié)果調(diào)用者被阻塞了,這段時間了做不了任何其它事情。 更郁悶的是，在等待IO結(jié)果的時間里,調(diào)用者所在線程此時無法騰出手來去響應(yīng)其它的請求，這真是太浪費資源了。拿read()操作來說吧,調(diào)用此函數(shù)的代碼會一直僵在此處直至它所讀的socket緩存中有數(shù)據(jù)到來。

相比之下，非阻塞同步是會立即返回控制權(quán)給調(diào)用者的。調(diào)用者不需要等等，它從調(diào)用的函數(shù)獲取兩種結(jié)果：要么此次調(diào)用成功進行了；要么系統(tǒng)返回錯誤標(biāo)識告訴調(diào)用者當(dāng)前資源不可用，你再等等或者再試一次看吧。比如read()操作,如果當(dāng)前socket無數(shù)據(jù)可讀，則立即返回EWOULBLOCK/EAGAIN，告訴調(diào)用read()者"數(shù)據(jù)還沒準(zhǔn)備好，你稍后再試".。

在非阻塞異步調(diào)用中，稍有不同。調(diào)用函數(shù)在立即返回時，還告訴調(diào)用者，這次請求已經(jīng)開始了。系統(tǒng)會使用另外的資源或者線程來完成這次調(diào)用操作，并在完成的時候知會調(diào)用者（比如通過回調(diào)函數(shù)）。拿Windows的ReadFile()或者POSIX的aio_read()來說,調(diào)用它之后，函數(shù)立即返回，操作系統(tǒng)在后臺同時開始讀操作。

在以上三種IO形式中，非阻塞異步是性能最高、伸縮性最好的。搞清楚了以上概念以后，我們再回過頭來看看，Reactor模式和Proactor模式。

此文詳細的闡述了基于TCP高性能的GOLDEN數(shù)據(jù)服務(wù)器模塊的設(shè)計以及解決方案 ，我們在文章的后面就不再提及阻塞式的方案了，因為阻塞式I/O實在是缺少可伸縮性，性能也達不到高性能服務(wù)器的要求。

兩種IO多路復(fù)用方案:Reactor和Proactor

一般情況下，I/O復(fù)用機制需要事件分離器(eventdemultiplexor ).事件分離器的作用，就是將那些讀寫事件源分發(fā)給各讀寫事件的處理者，就像送快遞的在樓下喊:誰的什么東西送了,快來拿吧。開發(fā)人員在開始的時候需要在事件分離器那里注冊感興趣的事件，并提供相應(yīng)的事件處理器(eventhandlers)，或者是回調(diào)函數(shù);事件分離器在適當(dāng)?shù)臅r候會將請求的事件分發(fā)給這些handler或者回調(diào)函數(shù)。

涉及到事件分離器的兩種模式稱為：Reactor和Proactor。Reactor模式是基于同步I/O的，而Proactor模式是和異步I/O相關(guān)的。在Reactor模式中，事件分離者等待某個事件或者是應(yīng)用或者是某個操作的狀態(tài)發(fā)生（比如文件描述符可讀寫，或者是socket可讀寫）,事件分離者就把這個事件傳給事先注冊的事件處理器或者事件處理函數(shù)或者回調(diào)函數(shù)，由后者來做實際的讀寫操作。

而在Proactor模式中，事件處理器(或者由事件分離器代為)直接發(fā)起一個異步讀寫操作(相當(dāng)于請求)，而實際的工作是由操作系統(tǒng)來完成的。發(fā)起時，需要提供的參數(shù)包括用于存放讀到數(shù)據(jù)的緩存區(qū)，讀的數(shù)據(jù)大小，或者用于存放外發(fā)數(shù)據(jù)的緩存區(qū)，以及這個請求完后的回調(diào)函數(shù)等信息。事件分離器得知了這個請求，它默默等待這個請求的完成，然后轉(zhuǎn)發(fā)完成事件給相應(yīng)的事件處理器或者事件處理函數(shù)或者回調(diào)。舉例來說，在Windows上事件處理器投遞了一個異步IO操作(稱有overlapped的技術(shù))，事件分離器等IOCompletion事件完成 ，這種異步模式的典型實現(xiàn)是基于操作系統(tǒng)底層異步API的，所以我們可稱之為“系統(tǒng)級別”的或者“真正意義上”的異步，因為具體的讀寫是由操作系統(tǒng)代勞的。

舉另外個例子來更好地理解Reactor與Proactor兩種模式的區(qū)別。這里我們只關(guān)注read操作，因為write操作也是差不多的。下面是Reactor的做法：

某個事件處理器宣稱它對某個socket上的讀事件很感興趣；

事件分離者等著這個事件的發(fā)生；

當(dāng)事件發(fā)生了，事件分離器被喚醒，這負責(zé)通知先前那個事件處理器；

事件處理器收到消息，于是去那個socket上讀數(shù)據(jù)了.如果需要，它再次宣稱對這個socket上的讀事件感興趣，一直重復(fù)上面的步驟；

下面再來看看真正意義的異步模式Proactor是如何做的：

事件處理器直接投遞發(fā)一個讀操作(當(dāng)然，操作系統(tǒng)必須支持這個異步操作)。這個時候，事件處理器根本不關(guān)心讀事件，它只管發(fā)這么個請求，它魂牽夢縈的是這個讀操作的完成事件。這個事件處理器很拽，發(fā)個命令就不管具體的事情了，只等著別人（系統(tǒng)）幫他搞定的時候給他回個話。

事件分離器等著這個讀事件的完成(比較下與Reactor的不同);

當(dāng)事件分離器默默等待完成事情到來的同時，操作系統(tǒng)已經(jīng)在一邊開始干活了，它從目標(biāo)讀取數(shù)據(jù)，放入用戶提供的緩存區(qū)中，最后通知事件分離器，這個事情我搞完了;

事件分離器通知之前的事件處理器:你吩咐的事情搞定了;

事件處理器這時會發(fā)現(xiàn)想要讀的數(shù)據(jù)已經(jīng)乖乖地放在他提供的緩存區(qū)中，想怎么處理都行了。如果有需要，事件處理器還像之前一樣發(fā)起另外一個讀操作，和上面的幾個步驟一樣。

現(xiàn)行做法

開源C++開發(fā)框架ACE（Adaptive Communication Enviromen） 提供了大量平臺獨立的底層并發(fā)支持類(線程、互斥量等).同時在更高一層它也提供了獨立的幾組C++類，用于實現(xiàn)Reactor及Proactor模式。 盡管它們都是平臺獨立的單元，但他們都提供了不同的接口.

ACE Proactor在MS-Windows上無論是性能還在健壯性都更勝一籌，這主要是由于Windows提供了一系列高效的底層異步API。

不幸的是,并不是所有操作系統(tǒng)都為底層異步提供健壯的支持。舉例來說,許多Unix系統(tǒng)就有麻煩. ACE中的Proactor在Unix上是使用Posix標(biāo)準(zhǔn)實現(xiàn)的異步操作，Posix中有一個AIO，Proactor使用AIO實現(xiàn)異步傳輸。但Linux在2.6以前版本中不支持AIO，而在2.6版本以后，部分支持AIO。就因為這個部分支持，所以，Posix的子類不能正常工作。因此,ACEReactor可能是Unix系統(tǒng)上更合適的解決方案.正因為系統(tǒng)底層的支持力度不一，為了在各系統(tǒng)上有更好的性能,開發(fā)者不得不維護獨立的好幾份代碼:為Windows準(zhǔn)備的ACEProactor以及為Unix系列提供的ACEReactor。

就像我們提到過的，真正的異步模式需要操作系統(tǒng)級別的支持。由于事件處理器及操作系統(tǒng)交互的差異，為Reactor和Proactor設(shè)計一種通用統(tǒng)一的外部接口是非常困難的。這也是設(shè)計通行開發(fā)框架的難點所在。

ACE Proactor 框架

怎樣發(fā)送和接收數(shù)據(jù)

ACEProactor框架包含了一組高度相關(guān)的類，其數(shù)量相對較多，我在進行以下描述的時候不可能按照順序討論它們，而又不進行提前引用。到最后我會描述完所有這些類。下面這些類給出了ACE Proactor框架的各個類以及它們之間的關(guān)系。可以把這個圖1-1當(dāng)作描述ACE Proactor框架實際應(yīng)用的范本。注意：類名中以ACE_開始的類名稱是ACE Procator框架中包含的類，而以golden_開始的類名稱是實際應(yīng)用范本提供的類。

下面的代碼聲明了一個類，它所完成的基本工作是處理接收和發(fā)送數(shù)據(jù)。

圖1.1ACE Proactor框架中的類

#include "ace/Asynch_IO.h"

class golden_aio_handler : public ACE_Service_Handler

{

public :

golden_aio_handler (golden_aio_acceptor *acc = 0) ;

virtual void open ( ACE_HANDLE new_handle,

ACE_Message_Block &message_block ) ;

virtual void handle_read_stream(

const ACE_Asynch_Read_Stream::Result &result);

virtual void handle_write_stream(

const ACE_Asynch_Write_Stream::Result &result);

private:

ACE_Asynch_Read_Stream reader_;

ACE_Asynch_Write_Stream writer_;

} ;

這段代碼首先包含了一些必需的頭文件，以引入這個例子使用的ACE Proactor框架類:

ACE_Service_Handler 在Proactor框架中創(chuàng)建事件處理器所用的目標(biāo)類 。

ACE_Handler ACE_Service_Handler的父類，定義了通過ACE_Proactor框架處理異步I/O完成事件所需要的接口。

ACE_Asynch_Read_Stream 用于在已經(jīng)連接的TCP/IP socket上發(fā)起讀操作的I/0工廠類。

ACE_Asynch_Write_Stream 用于在已經(jīng)連接的TCP/IP socket上發(fā)起寫操作的I/0工廠類。

Result 每個I/O工廠類都把Result定義為嵌在自己內(nèi)部的類，用以保存該工廠發(fā)起的每個操作的結(jié)果。所有的Result類都從ACE_Asynch_Result派生，并且增加了專用于它們所針對的I/O類型的數(shù)據(jù)和方法。因為每個異步I/O操作的發(fā)起和完成都是分離的、不同的事情，需要有一種機制來“記住”操作的參數(shù)，并且連同結(jié)果一起吧這些參數(shù)轉(zhuǎn)交給完成處理器。

設(shè)置事件處理器并發(fā)起I/O

當(dāng)TCP連接打開時，我們應(yīng)該把新socket的句柄傳給事件處理器對象，在這個例子中是golden_aio_handler。把句柄放在事件處理器里是有益的，原因如下：

• 它是socket的生命期一個方便的控制點，因為它是連接工廠的目標(biāo)。

• I/O操作最有可能從這個類發(fā)起。

在使用ACE_Proactor框架的異步連接建立類時golden_aio_handler::open()掛鉤方法會在新連接建立時被調(diào)用。下面是我們程序中的open()掛鉤:

void

golden_aio_handler::open(ACE_HANDLE new_handle, ACE_Message_Block &)

{

this->handle(new_handle);

//打開異步讀寫

reader_.open (*this, new_handle, 0, proactor ());

writer_.open (*this, new_handle, 0, proactor ());

//準(zhǔn)備讀的緩沖區(qū)

ACE_NEW_NORETURN(mblk_, ACE_Message_Block (SIZEOF_HEADER_WITH_CRC));

if (reader_.read (*mblk_,SIZEOF_HEADER_WITH_CRC) <0)

{

delete this ;

}

}

在一開始,我們使用繼承而得到的ACE_Handler::handle()方法保存新socket的句柄。該方法把句柄存儲在一個方便的地方，以便在析構(gòu)函數(shù)~golden_aio_handler()訪問或者用于其他用途。這是在這個類中實現(xiàn)的socket句柄生命期管理的一部分。

要發(fā)起I/O，必須初始化所需的I/O工廠對象。在存儲了socket句柄之后，open()方法會初始化reader_和writer_ I/O工廠對象，為發(fā)起I/O操作做準(zhǔn)備。兩個類的open()方法都是一樣的：

int open (ACE_Handler &handler,

ACE_HANDLE handle = ACE_INVALID_HANDLE,

const void *completion_key = 0,

ACE_Proactor *proactor = 0);

第一個參數(shù)表示工廠對象所發(fā)起的操作的完成事件處理器里。當(dāng)通過工廠對象發(fā)起的I/O操作完成時，ACE_Proactor框架會回調(diào)這個對象。這也是為什么該處理器對象叫做完成事件處理器的原因。在我們的程序中，golden_aio_handler對象是ACE_Handler的后代，即是讀操作也是寫操作的完成事件處理器，所以*this被用作處理器參數(shù)。handle是新傳入的socket句柄，completion_key參數(shù)只適用于windows默認傳入0即可，proactor參數(shù)會傳入一個在進程范圍的ACE_Procator單體對象。

程序中的open()掛鉤方法所做的最后一件事情，是調(diào)用ACE_Asynch_Read_Stream::read()方法，從而在新的socket上發(fā)起一個讀操作。ACE_Asynch_Read_Stream::read()函數(shù)如下：

int read (ACE_Message_Block &message_block,

size_t num_bytes_to_read,

const void *act = 0,

int priority = 0,

int signal_number = ACE_SIGRTMIN);

為傳輸指定一個ACE_Message_Block ,使得緩沖區(qū)管理變得更為容易，因為可以利用ACE_Message_Block的各種能力，以及它與ACE的其他部分的集成。在發(fā)起讀操作時，數(shù)據(jù)會被讀入開始于數(shù)據(jù)塊的寫指針處在的塊中，因為要被讀取的數(shù)據(jù)將被寫入塊中。

完成I/O操作

ACE_Proactor框架是基于事件的框架。I/O工廠登記“每個操作”與“該操作完成時應(yīng)回調(diào)的完成事件處理器”之間建立關(guān)聯(lián)。當(dāng)讀取完成時，ACE_Proactor框架會調(diào)用ACE_Handler::handle_read_stream()掛鉤方法：

void golden_aio_handler::handle_read_stream(

const ACE_Asynch_Read_Stream::Result &result)

{ ACE_Asynch_Read_Stream::Result &result

if (!result.success () || result.bytes_transferred () == 0)

delete this;

else if (result.bytes_transferred () < result.bytes_to_read ())

{

if (reader_.read (*mblk_, result.bytes_to_read () - result.bytes_transferred ()) < 0)

delete this ;

}

else if (mblk_->length () == SIZEOF_HEADER_WITH_CRC)

handle_msg_header();

else

{

if (handle_msg_pack()<0)

delete this ;

}

}

傳入的ACE_Asynch_Read_Stream::Result指向的是用于保存讀取操作結(jié)果的對象。每個I/O工廠類都會定義自己的Result類，即用于保存每個操作發(fā)起時所用的參數(shù)，又用于保存操作的結(jié)果。

如果讀操作讀取了任何數(shù)據(jù)，處理接收read到的報文數(shù)據(jù)包用handle_msg_pack函數(shù)，然后發(fā)起一個寫操作，把數(shù)據(jù)處理結(jié)果返回給對端。當(dāng)寫操作完成時，ACE_Proactor框架調(diào)用下面的handle_write_stream方法：

void golden_aio_handler::handle_write_stream(const ACE_Asynch_Write_Stream::Result &result)

{

if(reader_.read (*mblk_,SIZEOF_HEADER_WITH_CRC) < 0)

delete this;

}

不管寫操作是否成功完成，在該操作中使用的消息塊都會釋放。如果socket出了問題，先前發(fā)起的讀操作也會完成并出錯，而handle_read_stream()會清理對象和socket句柄。

圖1-2給出了本程序事件序列。

建立連接

ACE提供里兩個工廠類，用于通過ACE_Proactor框架前攝式地建立TCP/IP連接：

ACE_Asynch_Acceptor ， 用于發(fā)起被動的連接建立

ACE_Asynch_Connector ,用于發(fā)起主動的連接建立

圖1.2ACE Proactor異步回調(diào)序列圖

當(dāng)使用其中一個類建立TCP/IP連接時，ACE_Proactor框架會創(chuàng)建一個從ACE_Service_Handler派生的事件服務(wù)處理器，比如golden_aio_handler，用以處理新連接。ACE_Service_Handler類是

ACE_Proactor框架中所有用異步方式連接的服務(wù)的基類，從ACE_Handler派生，所以服務(wù)類也可以處理在服務(wù)中發(fā)起的I/O操作的完成.

ACE_Asynch_Acceptor是一個相當(dāng)容易使用的類，它的一個掛鉤方法是一個protected虛方法：make_handler()。Proactor框架調(diào)用這個方法獲取一個ACE_Service_Handler對象，用以為新連接提供服務(wù)。下面的代碼說明了這種情況：

golden_aio_handler * golden_aio_acceptor::make_handler (void)

{

///來一個連接，就新增一個句柄。在線程池中處理

golden_aio_handler *ih;

ACE_NEW_RETURN (ih, golden_aio_handler (this), 0);

if (clients_.insert (ih) == -1)

{

delete ih ;

return NULL ;

}

return ih;

}

return 0 ;

}

ACE_Proactor完成多路分離器

ACE_Proactor類負責(zé)驅(qū)動ACE_Proactor框架的完成處理，這個類等待完成事件的發(fā)生、把這些事件多路分離給相關(guān)聯(lián)的完成事件處理器，并分派每個完成處理器上適當(dāng)?shù)膾煦^方法。因此，要讓異步I/O完成事件處理器得以發(fā)生----無論是I/O還是連接建立----在Golden Server中都必須運行前攝器的時間循環(huán)。這通常很簡單，只需要把下面的代碼插入到應(yīng)用中就可以了：

int golden_aio::svc()

{

ACE_Proactor::instance()->proactor_run_event_loop ();

return 1 ;

}

可以通過兩種方式來使用ACE_Proactor，如上所示的程序代碼instance()，作為單體來使用。也可以通過實例化一個或多個實例來使用。這個能力被用于在一個進程中支持多個前攝器。如下代碼所示，這是應(yīng)用于鏡像發(fā)送和鏡像接收的前攝器

int golden_mirror_sender::svc()

{

proactor_sender_->proactor_run_event_loop ();

return 1 ;

}

int golden_mirror_receiver::svc()

{

proactor_recviver_->proactor_run_event_loop ();

return 1 ;

}

各種操作系統(tǒng)上的異步I/O設(shè)施會有很大的不同，為了在所有這些系統(tǒng)上維持統(tǒng)一的接口和編程方法，ACE_Proactor類使用了Bridge模式來維持靈活性和可擴展性，同時還使得ACE_Proactor框架能夠使用不同的異步I/O實現(xiàn)。

ACE_WIN32_Proactor類是Windows上的ACE_Proactor實現(xiàn)。使用了I/O完成端口進行完成事件檢測。在初始化異步操作工廠時，I/O句柄與前攝器的I/O完成端口被關(guān)聯(lián)在一起。在這種實現(xiàn)中，windows下的GetQueuedCompletionStatus()函數(shù)負責(zé)執(zhí)行事件循環(huán)，如下程序代碼

int golden_server::create_proactor()

{

ACE_Proactor::instance()->close_singleton();

impl_ = new ACE_WIN32_Proactor(0,1);

ACE_Proactor::instance(new ACE_Proactor(impl_,1),1) ;

return 0;

}

int golden_server::create_proactor_mirror_recviver()

{

ACE_NEW_RETURN(impl_mirror_recviver_, ACE_WIN32_Proactor(0,1),-1);

ACE_NEW_RETURN(mirror_recviver_proactor_, ACE_Proactor(impl_mirror_recviver_,1),-1);

return 0;

}

int golden_server::create_proactor_mirror_sender()

{

ACE_NEW_RETURN(impl_mirror_sender_, ACE_WIN32_Proactor(0,1),-1);

ACE_NEW_RETURN(mirror_sender_proactor_, ACE_Proactor(impl_mirror_sender_,1),-1);

return 0;

}

線程池

大多數(shù)網(wǎng)絡(luò)服務(wù)器都被設(shè)計成能同時處理多個客戶請求。使用反應(yīng)式事件處理、多個進程和多個線程。在構(gòu)建多線程服務(wù)器時，我們擁有多種選擇，包括：為每個請求派生一個新線程、為每個連接/會話派生一個新線程、預(yù)先派生一池受管線程，也就是創(chuàng)建一個線程池。在Golden Server設(shè)計中我們采用了了線程池的方法。

線程池模型有兩種變種，每種都有不同的性能特征：

半同步/半異步模型。在這種模型中，一個偵聽會異步的接收請求，并在某個隊列中緩沖它們。另外一組工作者線程負責(zé)同步地處理這些請求。

領(lǐng)導(dǎo)者/跟隨著模型。在這種模型總，有一個線程是領(lǐng)導(dǎo)者，其余線程是在線程池中的跟隨者。當(dāng)請求到達時，領(lǐng)導(dǎo)者會拾取它，并從跟隨者中選取一個新的領(lǐng)導(dǎo)者，然后繼續(xù)處理該請求。因此，在這種模型中，接收請求的線程池就是處理它的線程。

領(lǐng)導(dǎo)者/跟隨者模型中，只用了一組線程等待新請求，并處理請求。一個線程被選作領(lǐng)導(dǎo)者，阻塞在“到來的請求源”上，當(dāng)請求到達時，領(lǐng)導(dǎo)者線程首先獲取請求，把某個跟隨者提升為領(lǐng)導(dǎo)者，然后繼續(xù)處理所收到的請求。新領(lǐng)導(dǎo)者在請求源上等待新的請求，與此同時舊領(lǐng)導(dǎo)者會處理剛剛收到的請求，一旦就領(lǐng)導(dǎo)者完成處理，它就會作為跟隨者線程回到線程池的末尾。

領(lǐng)導(dǎo)者/跟隨者模型的一個優(yōu)點是性能得到了提高，因為不用進行線程間的上下文切換。但同時這種模型也是復(fù)雜的。在程序中單個ACE_Task封裝了線程池中的所有線程。

class golden_aio :public ACE_Task<ACE_SYNCH>

{

public:

golden_aio(int number_of_connection)；

/// ACE_TASK的虛擬方法。用來啟動svc。

virtual int open (void * = 0);

///初始化

virtual int init(u_short ,ACE_Proactor* );

///結(jié)束并關(guān)閉

virtual int fini();

/// Run by a daemon thread to handle deferred processing

virtual int svc (void);

};

int golden_aio::open (void * )

{

return activate (THR_NEW_LWP | THR_JOINABLE |THR_INHERIT_SCHED ,number_of_thread_);

}

int golden_aio::svc()

{

ACE_Proactor::instance()->proactor_run_event_loop ();

return 1 ;

}

每個線程啟動時，首先會通過調(diào)用activate(),將任務(wù)轉(zhuǎn)化為運行在一個或多個線程中的主動對象。主動對象執(zhí)行任務(wù)的svc()掛鉤方法。每個線程在執(zhí)行proactor_run_event_loop ()調(diào)用GetQueuedCompletionStatus?()。 如果沒有消息到達線程會阻塞在GetQueuedCompletionStatus?()函數(shù)上，直到有消息到來那么有一個線程便成了領(lǐng)導(dǎo)者線程。如果領(lǐng)導(dǎo)者線程能很快的處理完所有事情，領(lǐng)導(dǎo)者線程會再次進入等待狀態(tài)。如果領(lǐng)導(dǎo)者線程不能馬上處理完，則從跟隨者線程中指定一個新的領(lǐng)導(dǎo)者線程，自己去處理事件，不再當(dāng)領(lǐng)導(dǎo)者。

單體模型

在Golden Server中golden_user、golden_authorize、golden_startup、golden_prot、golden_system_info、golden_dir_visitor、golden_mirror_sender、golden_mirror_receiver采用單體實例模式。相關(guān)單體模式的概念，請自行參考相關(guān)手冊和書籍。

如何添加一個接口應(yīng)用

Goldensdk模塊

打開goldensdk.h頭文件，根據(jù)接口類型找到合適的位置，添加接口的聲明、接口的描述注釋。

打開goldensdk.cpp文件，添加接口的空實現(xiàn)。

打開goldensdk.def文件，添加接口名稱。

按照步驟完成Goldenserver模塊

在goldensdk.cpp文實現(xiàn)已經(jīng)添加的空接口。

Goldenserver模塊

在golden_message_protocol.h中添加自定義的報文數(shù)據(jù)結(jié)構(gòu)定義和報文消息ID , 命名規(guī)則如下GOLDEN_PACK_XXX、GOLDEN_PACK_XXX_RESULT、MESSAGE_XXX、MESSAGE_XXX_RESULT。

在golden_message_protocol.cpp中添加用來計算報文數(shù)據(jù)結(jié)構(gòu)大小的函數(shù)聲明和整編\解編數(shù)據(jù)流的函數(shù)聲明。命名規(guī)則如下：sizeof_GOLDEN_PACK_XXX()、sizeof_GOLDEN_PACK_XXX_RESULT()、int operator<<(ACE_OutputCDR &cdr , const GOLDEN_PACK_XXX &spack) ，int operator<<(ACE_OutputCDR &cdr , const GOLDEN_PACK_XXX_RESUL &spack);

在golden_message_protocol.cpp中添加用來計算報文數(shù)據(jù)結(jié)構(gòu)大小的函數(shù)實現(xiàn)和整編\解編數(shù)據(jù)流的函數(shù)實現(xiàn)。

在golden_message_protocol.cpp中添加全部變量_gstring中的內(nèi)容，用來描述報文內(nèi)容。

在goldeserver.h中的golden_aio_handler類中添加處理報文的成員函數(shù)聲明。命名規(guī)則如下：int msg_xxx() 、int msg_xxx_result() .

在goldeserver.cpp中添加處理報文的成員函數(shù)的空實現(xiàn)golden_aio_handler:: msg_xxx(), golden_aio_handler:: msg_xxx_result() .

在goldeserver.cpp的int golden_aio_handler::handle_msg_pack()函數(shù)中添加報文處理項。

實現(xiàn)f步驟中定義的成員函數(shù)空實現(xiàn)。

參考文獻

C++網(wǎng)絡(luò)編程卷一---運用ACE和模式消除復(fù)雜性

C++網(wǎng)絡(luò)編程卷二---基于ACE和框架的系統(tǒng)化復(fù)用

ACE程序員指南---網(wǎng)絡(luò)與系統(tǒng)編程的實用設(shè)計模式

設(shè)計模式：可復(fù)用面向?qū)ο筌浖幕A(chǔ)

總結(jié)

以上是生活随笔為你收集整理的基于ACE Proactor框架下高并发、大容量吞吐程序设计既最近的一个产品开发总结的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。