應用程序：一個異步的HTTP服務器的設計

　　假設我們要設計一個HTTP服務器，它的設計目標包括：高并發性、精簡（部分支持HTTP/1.1）、支持plug-in結構。在不少場合可能都有這個需求?？傮w上來說，HTTP服務器可以類比成一個基于多線程的操作系統：OS調度每個工作線程在適當的時候獲得執行，而工作線程提供服務（也就是處理HTTP請求）。在這個基礎上，主要的考慮就是調度粒度的大小，粒度太大的時候并發性會降低，而粒度太小又可能因為任務切換（考慮OS的Context Switching）而導致效率降低，所以這又是一個折衷的結果。類似于Apache（以及其他的HTTP服務器），我們可以把一個HTTP處理過程分為若干個狀態，基于這些狀態可以構造出一個HTTP處理的狀態機。這種情況下，我們就可以把每個狀態的處理作為調度的粒度。一個調度過程就是：一個工作線程從全局的任務隊列里取出一個HTTP_Context結構；根據當前的狀態完成相應處理；然后根據狀態機設置下一個狀態；再放回到全局的任務隊列里。這樣子，若干個HTTP狀態就可以通過這個調度策略構成一個完整HTTP處理過程。顯而易見，一個狀態對于下一個狀態處理的調用都可以認為是異步的。一個HTTP狀態機的設計如下圖所示。

　　工作線程的函數其實就是兩個操作：從狀態隊列里取出一個HTTP_Context，調用HTTP_Context的service()函數，周而復此。在這個架構上，就很容易引入異步I/O和Plug-in的機制了。事實上我們也可以使用基于事件（例如select/poll）的I/O策略來模擬異步I/O，實現中使用一個tb用戶線程就可以了。

　　對于異步I/O和Plug-in的調用，我們也是采用類似于Linux 2.6里面aio的重試方案，而異步完成的時候采用回調函數。在某個狀態上，如果系統需要I/O操作（recv或者send），則會請求一個異步I/O（操作系統提供的異步I/O或者由用戶線程模擬的異步I/O），這時候相應的HTTP_Context不會重新回到狀態隊列里，而在I/O完成的回調函數里面才會重新放回到狀態隊列，得到重新調度的機會。HTTP_Context得到重新調度的時候會檢查I/O狀態（這個可以通過一些標志位來完成），如果已經完成，則處理然后設置下一狀態，重新調度，否則可以重新請求一個新的I/O請求。Plug-in也可以使用類似的方案，比如說一個Plug-in要跟外部的一個服務器通信，這時候就可以在通信完成的時候才把HTTP_Context重新放回到狀態隊列。顯然，Plug-in跟HTTP狀態是多對多的關系，一個Plug-in可以在若干個關心的狀態注冊自身，同時還可以設置一些short-path來提高處理的效率。

　　結論

　　總的來說，異步調用的設計和應用歸根結底就是對多個主動對象的管理問題：如何提供執行的動力以及如何保證執行的順序邏輯。主要考慮的問題是主動對象的粒度以及執行方式，同步或者回調來完成順序的調度，或者使用近似的調度而加一些魯棒的錯誤處理機制來保證語義的正確。后者可以考慮在使用基于事件的socket的時候，readable事件的通知可以是冗余的，或者說可以比實際中發生的readable事件更多，這個時候使用非阻塞的socket,有些read()（或者recv()）會直接返回EWOULDBLOCK，系統只要考慮處理這種情況（使用non blocking socket而不是blocking socket），當例外的情況不多的時候是可以接受的。這時候可以說事件的報告就只是近似的。