前言

事件驅動為廣大的程式設計師所熟悉，其最為人津津樂道的是在圖形化介面程式設計中的應用；事實上，在網路程式設計中事件驅動也被廣泛使用，並大規模部署在高連線數高吞吐量的伺服器程式中，如 http 伺服器程式、ftp 伺服器程式等。相比於傳統的網路程式設計方式，事件驅動能夠極大的降低資源佔用，增大服務接待能力，並提高網路傳輸效率。

關於本文提及的伺服器模型，搜尋網路可以查閱到很多的實現程式碼，所以，本文將不拘泥於原始碼的陳列與分析，而側重模型的介紹和比較。使用 libev 事件驅動庫的伺服器模型將給出實現程式碼。

本文涉及到執行緒 / 時間圖例，只為表明執行緒在各個 IO 上確實存在阻塞時延，但並不保證時延比例的正確性和 IO 執行先後的正確性；另外，本文所提及到的介面也只是筆者熟悉的 Unix/Linux 介面，並未推薦 Windows 介面，讀者可以自行查閱對應的 Windows 介面。

阻塞型的網路程式設計介面

幾乎所有的程式設計師第一次接觸到的網路程式設計都是從 listen()、send()、recv()等介面開始的。使用這些介面可以很方便的構建伺服器 /客戶機的模型。

我們假設希望建立一個簡單的伺服器程式，實現向單個客戶機提供類似於“一問一答”的內容服務。

圖 1. 簡單的一問一答的伺服器 /客戶機模型

我們注意到，大部分的 socket介面都是阻塞型的。所謂阻塞型介面是指系統呼叫（一般是 IO介面）不返回呼叫結果並讓當前執行緒一直阻塞，只有當該系統呼叫獲得結果或者超時出錯時才返回。

實際上，除非特別指定，幾乎所有的 IO介面 (包括 socket 介面 )

多執行緒伺服器程式

應對多客戶機的網路應用，最簡單的解決方式是在伺服器端使用多執行緒（或多程序）。多執行緒（或多程序）的目的是讓每個連線都擁有獨立的執行緒（或程序），這樣任何一個連線的阻塞都不會影響其他的連線。

具體使用多程序還是多執行緒，並沒有一個特定的模式。傳統意義上，程序的開銷要遠遠大於執行緒，所以，如果需要同時為較多的客戶機提供服務，則不推薦使用多程序；如果單個服務執行體需要消耗較多的 CPU 資源，譬如需要進行大規模或長時間的資料運算或檔案訪問，則程序較為安全。通常，使用 pthread_create () 建立新執行緒，fork() 建立新程序。

我們假設對上述的伺服器 / 客戶機模型，提出更高的要求，即讓伺服器同時為多個客戶機提供一問一答的服務。於是有了如下的模型。

在上述的執行緒 / 時間圖例中，主執行緒持續等待客戶端的連線請求，如果有連線，則建立新執行緒，並在新執行緒中提供為前例同樣的問答服務。

很多初學者可能不明白為何一個 socket 可以 accept 多次。實際上，socket 的設計者可能特意為多客戶機的情況留下了伏筆，讓 accept() 能夠返回一個新的 socket。下面是 accept 介面的原型：

	 int accept(int s, struct sockaddr *addr, socklen_t *addrlen); 

輸入引數 s 是從 socket()，bind() 和 listen() 中沿用下來的 socket 控制代碼值。執行完 bind() 和 listen() 後，作業系統已經開始在指定的埠處監聽所有的連線請求，如果有請求，則將該連線請求加入請求佇列。呼叫 accept() 介面正是從 socket s 的請求佇列抽取第一個連線資訊，建立一個與 s 同類的新的 socket 返回控制代碼。新的 socket 控制代碼即是後續 read() 和 recv() 的輸入引數。如果請求隊列當前沒有請求，則 accept() 將進入阻塞狀態直到有請求進入佇列。

上述多執行緒的伺服器模型似乎完美的解決了為多個客戶機提供問答服務的要求，但其實並不盡然。如果要同時響應成百上千路的連線請求，則無論多執行緒還是多程序都會嚴重佔據系統資源，降低系統對外界響應效率，而執行緒與程序本身也更容易進入假死狀態。

很多程式設計師可能會考慮使用“執行緒池”或“連線池”。“執行緒池”旨在減少建立和銷燬執行緒的頻率，其維持一定合理數量的執行緒，並讓空閒的執行緒重新承擔新的執行任務。“連線池”維持連線的快取池，儘量重用已有的連線、減少建立和關閉連線的頻率。這兩種技術都可以很好的降低系統開銷，都被廣泛應用很多大型系統，如 websphere、tomcat 和各種資料庫等。

但是，“執行緒池”和“連線池”技術也只是在一定程度上緩解了頻繁呼叫 IO 介面帶來的資源佔用。而且，所謂“池”始終有其上限，當請求大大超過上限時，“池”構成的系統對外界的響應並不比沒有池的時候效果好多少。所以使用“池”必須考慮其面臨的響應規模，並根據響應規模調整“池”的大小。

對應上例中的所面臨的可能同時出現的上千甚至上萬次的客戶端請求，“執行緒池”或“連線池”或許可以緩解部分壓力，但是不能解決所有問題。

總之，多執行緒模型可以方便高效的解決小規模的服務請求，但面對大規模的服務請求，多執行緒模型並不是最佳方案。下一章我們將討論用非阻塞介面來嘗試解決這個問題。

使用select()介面的基於事件驅動的伺服器模型

大部分 Unix/Linux 都支援 select 函式，該函式用於探測多個檔案控制代碼的狀態變化。下面給出 select 介面的原型：

 FD_ZERO(int fd, fd_set* fds) 
 FD_SET(int fd, fd_set* fds) 
 FD_ISSET(int fd, fd_set* fds) 
 FD_CLR(int fd, fd_set* fds) 
 int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, 
        struct timeval *timeout) 

這裡，fd_set 型別可以簡單的理解為按 bit 位標記控制代碼的佇列，例如要在某 fd_set 中標記一個值為 16 的控制代碼，則該 fd_set 的第 16 個 bit 位被標記為 1。具體的置位、驗證可使用 FD_SET、FD_ISSET 等巨集實現。在 select() 函式中，readfds、writefds 和 exceptfds 同時作為輸入引數和輸出引數。如果輸入的 readfds 標記了 16 號控制代碼，則 select() 將檢測 16 號控制代碼是否可讀。在 select() 返回後，可以通過檢查 readfds 有否標記 16 號控制代碼，來判斷該“可讀”事件是否發生。另外，使用者可以設定 timeout 時間。

下面將重新模擬上例中從多個客戶端接收資料的模型。

上述模型只是描述了使用 select() 介面同時從多個客戶端接收資料的過程；由於 select() 介面可以同時對多個控制代碼進行讀狀態、寫狀態和錯誤狀態的探測，所以可以很容易構建為多個客戶端提供獨立問答服務的伺服器系統。

這裡需要指出的是，客戶端的一個 connect() 操作，將在伺服器端激發一個“可讀事件”，所以 select() 也能探測來自客戶端的 connect() 行為。

上述模型中，最關鍵的地方是如何動態維護 select() 的三個引數 readfds、writefds 和 exceptfds。作為輸入引數，readfds 應該標記所有的需要探測的“可讀事件”的控制代碼，其中永遠包括那個探測 connect() 的那個“母”控制代碼；同時，writefds 和 exceptfds 應該標記所有需要探測的“可寫事件”和“錯誤事件”的控制代碼 ( 使用 FD_SET() 標記 )。

作為輸出引數，readfds、writefds 和 exceptfds 中的儲存了 select() 捕捉到的所有事件的控制代碼值。程式設計師需要檢查的所有的標記位 ( 使用 FD_ISSET() 檢查 )，以確定到底哪些控制代碼發生了事件。

上述模型主要模擬的是“一問一答”的服務流程，所以，如果 select() 發現某控制代碼捕捉到了“可讀事件”，伺服器程式應及時做 recv() 操作，並根據接收到的資料準備好待發送資料，並將對應的控制代碼值加入 writefds，準備下一次的“可寫事件”的 select() 探測。同樣，如果 select() 發現某控制代碼捕捉到“可寫事件”，則程式應及時做 send() 操作，並準備好下一次的“可讀事件”探測準備。下圖描述的是上述模型中的一個執行週期。

這種模型的特徵在於每一個執行週期都會探測一次或一組事件，一個特定的事件會觸發某個特定的響應。我們可以將這種模型歸類為“事件驅動模型”。

相比其他模型，使用 select() 的事件驅動模型只用單執行緒（程序）執行，佔用資源少，不消耗太多 CPU，同時能夠為多客戶端提供服務。如果試圖建立一個簡單的事件驅動的伺服器程式，這個模型有一定的參考價值。

但這個模型依舊有著很多問題。

首先，select() 介面並不是實現“事件驅動”的最好選擇。因為當需要探測的控制代碼值較大時，select() 介面本身需要消耗大量時間去輪詢各個控制代碼。很多作業系統提供了更為高效的介面，如 linux 提供了 epoll，BSD 提供了 kqueue，Solaris 提供了 /dev/poll …。如果需要實現更高效的伺服器程式，類似 epoll 這樣的介面更被推薦。遺憾的是不同的作業系統特供的 epoll 介面有很大差異，所以使用類似於 epoll 的介面實現具有較好跨平臺能力的伺服器會比較困難。

其次，該模型將事件探測和事件響應夾雜在一起，一旦事件響應的執行體龐大，則對整個模型是災難性的。如下例，龐大的執行體 1 的將直接導致響應事件 2 的執行體遲遲得不到執行，並在很大程度上降低了事件探測的及時性。

幸運的是，有很多高效的事件驅動庫可以遮蔽上述的困難，常見的事件驅動庫有 libevent 庫，還有作為 libevent 替代者的 libev 庫。這些庫會根據作業系統的特點選擇最合適的事件探測介面，並且加入了訊號 (signal) 等技術以支援非同步響應，這使得這些庫成為構建事件驅動模型的不二選擇。下章將介紹如何使用 libev 庫替換 select 或 epoll 介面，實現高效穩定的伺服器模型。

使用事件驅動庫libev的伺服器模型

Libev 是一種高效能事件迴圈 / 事件驅動庫。作為 libevent 的替代作品，其第一個版本釋出與 2007 年 11 月。Libev 的設計者聲稱 libev 擁有更快的速度，更小的體積，更多功能等優勢，這些優勢在很多測評中得到了證明。正因為其良好的效能，很多系統開始使用 libev 庫。本章將介紹如何使用 Libev 實現提供問答服務的伺服器。

（事實上，現存的事件迴圈 / 事件驅動庫有很多，作者也無意推薦讀者一定使用 libev 庫，而只是為了說明事件驅動模型給網路伺服器程式設計帶來的便利和好處。大部分的事件驅動庫都有著與 libev 庫相類似的介面，只要明白大致的原理，即可靈活挑選合適的庫。）

與前章的模型類似，libev 同樣需要迴圈探測事件是否產生。Libev 的迴圈體用 ev_loop 結構來表達，並用 ev_loop( ) 來啟動。

	 void ev_loop( ev_loop* loop, int flags ) 

Libev 支援八種事件型別，其中包括 IO 事件。一個 IO 事件用 ev_io 來表徵，並用 ev_io_init() 函式來初始化：

	 void ev_io_init(ev_io *io, callback, int fd, int events) 

初始化內容包括回撥函式 callback，被探測的控制代碼 fd 和需要探測的事件，EV_READ 表“可讀事件”，EV_WRITE 表“可寫事件”。

現在，使用者需要做的僅僅是在合適的時候，將某些 ev_io 從 ev_loop 加入或剔除。一旦加入，下個迴圈即會檢查 ev_io 所指定的事件有否發生；如果該事件被探測到，則 ev_loop 會自動執行 ev_io 的回撥函式 callback()；如果 ev_io 被登出，則不再檢測對應事件。

無論某 ev_loop 啟動與否，都可以對其新增或刪除一個或多個 ev_io，新增刪除的介面是 ev_io_start() 和 ev_io_stop()。

	 void ev_io_start( ev_loop *loop, ev_io* io ) 
	 void ev_io_stop( EV_A_* ) 

由此，我們可以容易得出如下的“一問一答”的伺服器模型。由於沒有考慮伺服器端主動終止連線機制，所以各個連線可以維持任意時間，客戶端可以自由選擇退出時機。

上述模型可以接受任意多個連線，且為各個連線提供完全獨立的問答服務。藉助 libev 提供的事件迴圈 / 事件驅動介面，上述模型有機會具備其他模型不能提供的高效率、低資源佔用、穩定性好和編寫簡單等特點。

由於傳統的 web 伺服器，ftp 伺服器及其他網路應用程式都具有“一問一答”的通訊邏輯，所以上述使用 libev 庫的“一問一答”模型對構建類似的伺服器程式具有參考價值；另外，對於需要實現遠端監視或遠端遙控的應用程式，上述模型同樣提供了一個可行的實現方案。

總結

本文圍繞如何構建一個提供“一問一答”的伺服器程式，先後討論了用阻塞型的 socket 介面實現的模型，使用多執行緒的模型，使用 select() 介面的基於事件驅動的伺服器模型，直到使用 libev 事件驅動庫的伺服器模型。文章對各種模型的優缺點都做了比較，從比較中得出結論，即使用“事件驅動模型”可以的實現更為高效穩定的伺服器程式。文中描述的多種模型可以為讀者的網路程式設計提供參考價值。