## 事件驅動 通常，我們寫服務器處理模型的程序時，有以下幾種模型： * 每收到一個請求，創建一個新的進程，來處理該請求； * 每收到一個請求，創建一個新的線程，來處理該請求； * 每收到一個請求，放入一個事件列表，讓主進程通過非阻塞I/O方式來處理請求，通常也可以理解為協程模式。 第（1）種方法，由于創建新的進程的開銷比較大，所以，會導致服務器性能比較差,但實現比較簡單。 第（2）種方式，由于要涉及到線程的同步，有可能會面臨死鎖等問題。 第（3）種方式，在寫應用程序代碼時，邏輯比前面兩種都復雜。 綜合考慮各方面因素，一般普遍認為第（3）種方式是大多數網絡服務器采用的方式 ## 事件驅動模型 目前大部分的UI編程都是事件驅動模型，如很多UI平臺都會提供onClick()事件，這個事件就代表鼠標按下事件。事件驅動模型大體思路如下： 1\. 有一個事件（消息）隊列； 2\. 鼠標按下時，往這個隊列中增加一個點擊事件（消息）； 3\. 有個循環，不斷從隊列取出事件，根據不同的事件，調用不同的函數，如onClick()、onKeyDown()等； 4\. 事件（消息）一般都各自保存各自的處理函數指針，這樣，每個消息都有獨立的處理函數；  　　事件驅動編程是一種編程范式，這里程序的執行流由外部事件來決定。它的特點是包含一個事件循環，當外部事件發生時使用回調機制來觸發相應的處理。另外兩種常見的編程范式是（單線程）同步以及多線程編程。 　　用例子來比較和對比一下單線程、多線程以及事件驅動編程模型。下圖展示了隨著時間的推移，這三種模式下程序所做的工作。這個程序有3個任務需要完成，每個任務都在等待I/O操作時阻塞自身。阻塞在I/O操作上所花費的時間已經用灰色框標示出來了。  　　在單線程同步模型中，任務按照順序執行。如果某個任務因為I/O而阻塞，其他所有的任務都必須等待，直到它完成之后它們才能依次執行。這種明確的執行順序和串行化處理的行為是很容易推斷得出的。如果任務之間并沒有互相依賴的關系，但仍然需要互相等待的話這就使得程序不必要的降低了運行速度。 　　在多線程版本中，這3個任務分別在獨立的線程中執行。這些線程由操作系統來管理，在多處理器系統上可以并行處理。這使得當某個線程阻塞在某個資源的同時其他線程得以繼續執行。與完成類似功能的同步程序相比，這種方式更有效率，但程序員必須寫代碼來保護共享資源，防止其被多個線程同時訪問。 　　在事件驅動版本的程序中，3個任務交錯執行，但仍然在一個單獨的線程控制中。當處理I/O操作時，注冊一個回調函數到事件循環中，然后當I/O操作完成時繼續執行。回調函數描述了該如何處理某個事件。事件循環輪詢所有的事件，當事件到來時將它們分配給等待處理事件的回調函數。這種方式讓程序盡可能的得以執行而不需要用到額外的線程。 當我們面對如下的環境時，事件驅動模型通常是一個好的選擇： 1. 程序中有許多任務。 2. 任務之間高度獨立（因此它們不需要互相通信，或者等待彼此）。 3. 在等待事件到來時，某些任務會阻塞。 ?　　**此處要提出一個問題，就是，上面的事件驅動模型中，只要一遇到IO就注冊一個事件，然后主程序就可以繼續干其它的事情了，只到io處理完畢后，繼續恢復之前中斷的任務，這本質上是怎么實現的呢？同步IO和異步IO，阻塞IO和非阻塞IO分別是什么，到底有什么區別？不同的人在不同的上下文下給出的答案是不同的。所以先限定一下本文的上下文。*`本文討論的背景是Linux環境下的network IO。`*** ## ?概念說明 ### 用戶空間和內核空間 　　現在操作系統都是采用虛擬存儲器，那么對32位操作系統而言，它的尋址空間（虛擬存儲空間）為4G（2的32次方）。操作系統的核心是內核，獨立于普通的應用程序，可以訪問受保護的內存空間，也有訪問底層硬件設備的所有權限。為了保證用戶進程不能直接操作內核（kernel），保證內核的安全，操心系統將虛擬空間劃分為兩部分，一部分為內核空間，一部分為用戶空間。針對linux操作系統而言，將最高的1G字節（從虛擬地址0xC0000000到0xFFFFFFFF），供內核使用，稱為內核空間，而將較低的3G字節（從虛擬地址0x00000000到0xBFFFFFFF），供各個進程使用，稱為用戶空間。 ### 進程切換 　　為了控制進程的執行，內核必須有能力掛起正在CPU上運行的進程，并恢復以前掛起的某個進程的執行。這種行為被稱為進程切換。因此可以說，任何進程都是在操作系統內核的支持下運行的，是與內核緊密相關的。 ### 進程阻塞 　　正在執行的進程，由于期待的某些事件未發生，如請求系統資源失敗、等待某種操作的完成、新數據尚未到達或無新工作做等，則由系統自動執行阻塞原語(Block)，使自己由運行狀態變為阻塞狀態。可見，進程的阻塞是進程自身的一種主動行為，也因此只有處于運行態的進程（獲得CPU），才可能將其轉為阻塞狀態。當進程進入阻塞狀態，是不占用CPU資源的。 ### 文件描述符 　　文件描述符（File descriptor）是計算機科學中的一個術語，是一個用于表述指向文件的引用的抽象化概念。文件描述符在形式上是一個非負整數。實際上，它是一個索引值，指向內核為每一個進程所維護的該進程打開文件的記錄表。當程序打開一個現有文件或者創建一個新文件時，內核向進程返回一個文件描述符。在程序設計中，一些涉及底層的程序編寫往往會圍繞著文件描述符展開。但是文件描述符這一概念往往只適用于UNIX、Linux這樣的操作系統。 ### 緩存I/O 　　緩存 I/O 又被稱作標準 I/O，大多數文件系統的默認 I/O 操作都是緩存 I/O。在 Linux 的緩存 I/O 機制中，操作系統會將 I/O 的數據緩存在文件系統的頁緩存中，也就是說，**數據會先被拷貝到操作系統內核的緩沖區中，然后才會從操作系統內核的緩沖區拷貝到應用程序的地址空間**。緩存 I/O 的缺點：數據在傳輸過程中需要在應用程序地址空間和內核進行多次數據拷貝操作，這些數據拷貝操作所帶來的 CPU 以及內存開銷是非常大的。 ## I/O模式 　　剛才說了，對于一次IO訪問（以read舉例），數據會先被拷貝到操作系統內核的緩沖區中，然后才會從操作系統內核的緩沖區拷貝到應用程序的地址空間。所以說，當一個read操作發生時，它會經歷兩個階段： 1\. 等待數據準備 (Waiting for the data to be ready) 2\. 將數據從內核拷貝到進程中 (Copying the data from the kernel to the process) 正式因為這兩個階段，linux系統產生了下面五種網絡模式的方案。 * 阻塞 I/O（blocking IO） * 非阻塞 I/O（nonblocking IO） * I/O 多路復用（ IO multiplexing） * 信號驅動 I/O（ signal driven IO） * 異步 I/O（asynchronous IO） 注：由于signal driven IO在實際中并不常用，所以這只提及剩下的四種IO Model。 ### 阻塞 I/O（blocking IO） 在linux中，默認情況下所有的socket都是blocking，一個典型的讀操作流程大概是這樣：  　　當用戶進程調用了recvfrom這個系統調用，kernel就開始了IO的第一個階段：準備數據（對于網絡IO來說，很多時候數據在一開始還沒有到達。比如，還沒有收到一個完整的UDP包。這個時候kernel就要等待足夠的數據到來）。這個過程需要等待，也就是說數據被拷貝到操作系統內核的緩沖區中是需要一個過程的。而在用戶進程這邊，整個進程會被阻塞（當然，是進程自己選擇的阻塞）。當kernel一直等到數據準備好了，它就會將數據從kernel中拷貝到用戶內存，然后kernel返回結果，用戶進程才解除block的狀態，重新運行起來。 > 所以，blocking IO的特點就是在IO執行的兩個階段都被block了。 ### 非阻塞 I/O（nonblocking IO） linux下，可以通過設置socket使其變為non-blocking。當對一個non-blocking socket執行讀操作時，流程是這個樣子：  　　當用戶進程發出read操作時，如果kernel中的數據還沒有準備好，那么它并不會block用戶進程，而是立刻返回一個error。從用戶進程角度講 ，它發起一個read操作后，并不需要等待，而是馬上就得到了一個結果。用戶進程判斷結果是一個error時，它就知道數據還沒有準備好，于是它可以再次發送read操作。一旦kernel中的數據準備好了，并且又再次收到了用戶進程的system call，那么它馬上就將數據拷貝到了用戶內存，然后返回。　　 > 所以，nonblocking IO的特點是用戶進程需要不斷的主動詢問kernel數據好了沒有。 ### I/O 多路復用（ IO multiplexing） IO multiplexing就是我們說的select，poll，epoll，有些地方也稱這種IO方式為event driven IO。select/epoll的好處就在于單個process就可以同時處理多個網絡連接的IO。它的基本原理就是select，poll，epoll這個function會不斷的輪詢所負責的所有socket，當某個socket有數據到達了，就通知用戶進程。  　　當用戶進程調用了select，整個進程就會被block，而同時，kernel會“監視”所有select負責的socket，當任何一個socket中的數據準備好了，select就會返回。這個時候用戶進程再調用read操作，將數據從kernel拷貝到用戶進程。 > 所以，I/O 多路復用的特點是通過一種機制一個進程能同時等待多個文件描述符，而這些文件描述符（套接字描述符）其中的任意一個進入讀就緒狀態，select()函數就可以返回。 　　這個圖和blocking IO的圖其實并沒有太大的不同，但是，用select的優勢在于它可以同時處理多個connection。所以，如果處理的連接數不是很高的話，使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server性能更好，可能延遲還更大。select/epoll的優勢并不是對于單個連接能處理得更快，而是在于能處理更多的連接。在IO multiplexing Model中，實際中，對于每一個socket，一般都設置成為non-blocking，但是，如上圖所示，整個用戶的process其實是一直被block的。只不過process是被select這個函數block，而不是被socket IO給block。 ### 異步 I/O（asynchronous IO） Linux下的asynchronous IO其實用得很少。先看一下它的流程：  　　用戶進程發起read操作之后，立刻就可以開始去做其它的事。而另一方面，從kernel的角度，當它受到一個asynchronous read之后，首先它會立刻返回，所以不會對用戶進程產生任何block。然后，kernel會等待數據準備完成，然后將數據拷貝到用戶內存，當這一切都完成之后，kernel會給用戶進程發送一個signal，告訴它read操作完成了。 ## 總結 各個IO Model的比較如圖所示：  　　通過上面的圖片，可以發現non-blocking IO和asynchronous IO的區別還是很明顯的。在non-blocking IO中，雖然進程大部分時間都不會被block，但是它仍然要求進程去主動的check，并且當數據準備完成以后，也需要進程主動的再次調用recvfrom來將數據拷貝到用戶內存。而asynchronous IO則完全不同。它就像是用戶進程將整個IO操作交給了他人（kernel）完成，然后他人做完后發信號通知。在此期間，用戶進程不需要去檢查IO操作的狀態，也不需要主動的去拷貝數據。 ## IO多路復用詳解 ### select select最早于1983年出現在4.2BSD中，它通過一個select()系統調用來監視多個文件描述符的數組，當select()返回后，該數組中就緒的文件描述符便會被內核修改標志位，使得進程可以獲得這些文件描述符從而進行后續的讀寫操作。select目前幾乎在所有的平臺上支持，其良好跨平臺支持也是它的一個優點，事實上從現在看來，這也是它所剩不多的優點之一。select的一個缺點在于單個進程能夠監視的文件描述符的數量存在最大限制，在Linux上一般為1024，不過可以通過修改宏定義甚至重新編譯內核的方式提升這一限制。另外，select()所維護的存儲大量文件描述符的數據結構，隨著文件描述符數量的增大，其復制的開銷也線性增長。同時，由于網絡響應時間的延遲使得大量TCP連接處于非活躍狀態，但調用select()會對所有socket進行一次線性掃描，所以這也浪費了一定的開銷。 ### poll 　　poll在1986年誕生于System V Release 3，它和select在本質上沒有多大差別，但是poll沒有最大文件描述符數量的限制。poll和select同樣存在一個缺點就是，包含大量文件描述符的數組被整體復制于用戶態和內核的地址空間之間，而不論這些文件描述符是否就緒，它的開銷隨著文件描述符數量的增加而線性增大。另外，select()和poll()將就緒的文件描述符告訴進程后，如果進程沒有對其進行IO操作，那么下次調用select()和poll()的時候將再次報告這些文件描述符，所以它們一般不會丟失就緒的消息，這種方式稱為水平觸發（Level Triggered）。 ### epoll 　　直到Linux2.6才出現了由內核直接支持的實現方法，那就是epoll，它幾乎具備了之前所說的一切優點，被公認為Linux2.6下性能最好的多路I/O就緒通知方法。epoll可以同時支持水平觸發和邊緣觸發（Edge Triggered，只告訴進程哪些文件描述符剛剛變為就緒狀態，它只說一遍，如果我們沒有采取行動，那么它將不會再次告知，這種方式稱為邊緣觸發），理論上邊緣觸發的性能要更高一些，但是代碼實現相當復雜。epoll同樣只告知那些就緒的文件描述符，而且當我們調用epoll\_wait()獲得就緒文件描述符時，返回的不是實際的描述符，而是一個代表就緒描述符數量的值，你只需要去epoll指定的一個數組中依次取得相應數量的文件描述符即可，這里也使用了內存映射（mmap）技術，這樣便徹底省掉了這些文件描述符在系統調用時復制的開銷。另一個本質的改進在于epoll采用基于事件的就緒通知方式。在select/poll中，進程只有在調用一定的方法后，內核才對所有監視的文件描述符進行掃描，而epoll事先通過epoll\_ctl()來注冊一個文件描述符，一旦基于某個文件描述符就緒時，內核會采用類似callback的回調機制，迅速激活這個文件描述符，當進程調用epoll\_wait()時便得到通知。