Reactor與 Proactor

基本概念

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

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

• • 什么是阻塞和非阻塞

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

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

非阻塞方式下，讀取或者寫入函數會立即返回一個狀態值。

• • 什么是同步和異步

同步和異步是針對應用程序和內核的交互而言的。

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

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

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

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

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

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

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

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

• • ???異步阻塞IO：

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

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

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

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

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

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

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

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

兩種IO多路復用方案:Reactor和Proactor

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

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

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

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

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

事件分離者等著這個事件的發生；

當事件發生了，事件分離器被喚醒，這負責通知先前那個事件處理器；

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

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

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

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

當事件分離器默默等待完成事情到來的同時，操作系統已經在一邊開始干活了，它從目標讀取數據，放入用戶提供的緩存區中，最后通知事件分離器，這個事情我搞完了;

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

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

現行做法

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

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

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

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

ACE Proactor 框架

怎樣發送和接收數據

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

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

圖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框架中創建事件處理器所用的目標類 。

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

ACE_Asynch_Read_Stream 用于在已經連接的TCP/IP socket上發起讀操作的I/0工廠類。

ACE_Asynch_Write_Stream 用于在已經連接的TCP/IP socket上發起寫操作的I/0工廠類。

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

設置事件處理器并發起I/O

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

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

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

在使用ACE_Proactor框架的異步連接建立類時golden_aio_handler::open()掛鉤方法會在新連接建立時被調用。下面是我們程序中的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 ());

//準備讀的緩沖區

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的句柄。該方法把句柄存儲在一個方便的地方，以便在析構函數~golden_aio_handler()訪問或者用于其他用途。這是在這個類中實現的socket句柄生命期管理的一部分。

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

int open (ACE_Handler &handler,

ACE_HANDLE handle = ACE_INVALID_HANDLE,

const void *completion_key = 0,

ACE_Proactor *proactor = 0);

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

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

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 ,使得緩沖區管理變得更為容易，因為可以利用ACE_Message_Block的各種能力，以及它與ACE的其他部分的集成。在發起讀操作時，數據會被讀入開始于數據塊的寫指針處在的塊中，因為要被讀取的數據將被寫入塊中。

完成I/O操作

ACE_Proactor框架是基于事件的框架。I/O工廠登記“每個操作”與“該操作完成時應回調的完成事件處理器”之間建立關聯。當讀取完成時，ACE_Proactor框架會調用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指向的是用于保存讀取操作結果的對象。每個I/O工廠類都會定義自己的Result類，即用于保存每個操作發起時所用的參數，又用于保存操作的結果。

如果讀操作讀取了任何數據，處理接收read到的報文數據包用handle_msg_pack函數，然后發起一個寫操作，把數據處理結果返回給對端。當寫操作完成時，ACE_Proactor框架調用下面的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出了問題，先前發起的讀操作也會完成并出錯，而handle_read_stream()會清理對象和socket句柄。

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

建立連接

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

ACE_Asynch_Acceptor ， 用于發起被動的連接建立

ACE_Asynch_Connector ,用于發起主動的連接建立

圖1.2ACE Proactor異步回調序列圖

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

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

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

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類負責驅動ACE_Proactor框架的完成處理，這個類等待完成事件的發生、把這些事件多路分離給相關聯的完成事件處理器，并分派每個完成處理器上適當的掛鉤方法。因此，要讓異步I/O完成事件處理器得以發生----無論是I/O還是連接建立----在Golden Server中都必須運行前攝器的時間循環。這通常很簡單，只需要把下面的代碼插入到應用中就可以了：

int golden_aio::svc()

{

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

return 1 ;

}

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

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 ;

}

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

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

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;

}

線程池

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

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

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

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

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

領導者/跟隨者模型的一個優點是性能得到了提高，因為不用進行線程間的上下文切換。但同時這種模型也是復雜的。在程序中單個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* );

///結束并關閉

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 ;

}

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

單體模型

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

如何添加一個接口應用

Goldensdk模塊

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

打開goldensdk.cpp文件，添加接口的空實現。

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

按照步驟完成Goldenserver模塊

在goldensdk.cpp文實現已經添加的空接口。

Goldenserver模塊

在golden_message_protocol.h中添加自定義的報文數據結構定義和報文消息ID , 命名規則如下GOLDEN_PACK_XXX、GOLDEN_PACK_XXX_RESULT、MESSAGE_XXX、MESSAGE_XXX_RESULT。

在golden_message_protocol.cpp中添加用來計算報文數據結構大小的函數聲明和整編\解編數據流的函數聲明。命名規則如下：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中添加用來計算報文數據結構大小的函數實現和整編\解編數據流的函數實現。

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

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

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

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

實現f步驟中定義的成員函數空實現。

參考文獻

C++網絡編程卷一---運用ACE和模式消除復雜性

C++網絡編程卷二---基于ACE和框架的系統化復用

ACE程序員指南---網絡與系統編程的實用設計模式

設計模式：可復用面向對象軟件的基礎

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。