事件驅動模型

與傳統編程模式不同，事件驅動程序在啟動之後，就在那等待，等待什麽呢？等待被事件觸發。傳統編程下也有“等待”的時候，比如在代碼塊D中，你定義了一個input()，需要用戶輸入數據。但這與下面的等待不同，傳統編程的“等待”，比如input()，你作為程序編寫者是知道或者強制用戶輸入某個東西的，或許是數字，或許是文件名稱，如果用戶輸入錯誤，你還需要提醒他，並請他重新輸入。事件驅動程序的等待則是完全不知道，也不強制用戶輸入或者幹什麽。只要某一事件發生，那程序就會做出相應的“反應”。這些事件包括：輸入信息、鼠標、敲擊鍵盤上某個鍵還有系統內部定時器觸發。

事件驅動模型介紹

通常，我們寫服務器處理模型的程序時，有以下幾種模型：

（1）每收到一個請求，創建一個新的進程，來處理該請求； 
（2）每收到一個請求，創建一個新的線程，來處理該請求； 
（3）每收到一個請求，放入一個事件列表，讓主進程通過非阻塞I/O方式來處理請求

第三種就是協程、事件驅動的方式，一般普遍認為第（3）種方式是大多數網絡服務器采用的方式

目前大部分的UI編程都是事件驅動模型，如很多UI平臺都會提供onClick()事件，這個事件就代表鼠標按下事件。事件驅動模型大體思路如下：

1. 有一個事件（消息）隊列；
2. 鼠標按下時，往這個隊列中增加一個點擊事件（消息）；
3. 有個循環，不斷從隊列取出事件，根據不同的事件，調用不同的函數，如onClick()、onKeyDown()等；
4. 事件（消息）一般都各自保存各自的處理函數指針，這樣，每個消息都有獨立的處理函數；

事件驅動編程是一種編程範式，這裏程序的執行流由外部事件來決定。它的特點是包含一個事件循環，當外部事件發生時使用回調機制來觸發相應的處理。另外兩種常見的編程範式是（單線程）同步以及多線程編程。

IO多路復用

前面是用協程實現的IO阻塞自動切換，那麽協程又是怎麽實現的，在原理是是怎麽實現的。如何去實現事件驅動的情況下IO的自動阻塞的切換，這個學名叫什麽呢？ => IO多路復用
比如socketserver，多個客戶端連接，單線程下實現並發效果，就叫多路復用。

緩存 I/O

緩存 I/O 又被稱作標準 I/O，大多數文件系統的默認 I/O 操作都是緩存 I/O。在 Linux 的緩存 I/O 機制中，操作系統會將 I/O 的數據緩存在文件系統的頁緩存（ page cache ）中，也就是說，數據會先被拷貝到操作系統內核的緩沖區中，然後才會從操作系統內核的緩沖區拷貝到應用程序的地址空間。用戶空間沒法直接訪問內核空間的，內核態到用戶態的數據拷貝

同步（synchronous） IO和異步（asynchronous） IO，阻塞（blocking） IO和非阻塞（non-blocking）IO

對於一個network IO (這裏我們以read舉例)，它會涉及到兩個系統對象，一個是調用這個IO的process (or thread)，另一個就是系統內核(kernel)。當一個read操作發生時，它會經歷兩個階段：
1 等待數據準備 (Waiting for the data to be ready)
2 將數據從內核拷貝到進程中 (Copying the data from the kernel to the process)
記住這兩點很重要，因為這些IO Model的區別就是在兩個階段上各有不同的情況。

blocking IO （阻塞IO）

當用戶進程調用了recvfrom這個系統調用，kernel就開始了IO的第一個階段：準備數據。對於network io來說，很多時候數據在一開始還沒有到達（比如，還沒有收到一個完整的UDP包），這個時候kernel就要等待足夠的數據到來。而在用戶進程這邊，整個進程會被阻塞。當kernel一直等到數據準備好了，它就會將數據從kernel中拷貝到用戶內存，然後kernel返回結果，用戶進程才解除block的狀態，重新運行起來。
所以，blocking IO的特點就是在IO執行的兩個階段都被block了。

non-blocking IO（非阻塞IO）

linux下，可以通過設置socket使其變為non-blocking。當對一個non-blocking socket執行讀操作時，流程是這個樣子：

從圖中可以看出，當用戶進程發出read操作時，如果kernel中的數據還沒有準備好，那麽它並不會block用戶進程，而是立刻返回一個error。從用戶進程角度講 ，它發起一個read操作後，並不需要等待，而是馬上就得到了一個結果。用戶進程判斷結果是一個error時，它就知道數據還沒有準備好，於是它可以再次發送read操作。一旦kernel中的數據準備好了，並且又再次收到了用戶進程的system call，那麽它馬上就將數據拷貝到了用戶內存，然後返回。
所以，用戶進程其實是需要不斷的主動詢問kernel數據好了沒有。

IO multiplexing（IO多路復用）

IO multiplexing這個詞可能有點陌生，但是如果我說select，epoll，大概就都能明白了。有些地方也稱這種IO方式為event driven IO。我們都知道，select/epoll的好處就在於單個process就可以同時處理多個網絡連接的IO。它的基本原理就是select/epoll這個function會不斷的輪詢所負責的所有socket，當某個socket有數據到達了，就通知用戶進程。它的流程如圖：

當用戶進程調用了select，那麽整個進程會被block，而同時，kernel會“監視”所有select負責的socket，當任何一個socket中的數據準備好了，select就會返回。這個時候用戶進程再調用read操作，將數據從kernel拷貝到用戶進程。
這個圖和blocking IO的圖其實並沒有太大的不同，事實上，還更差一些。因為這裏需要使用兩個system call (select 和 recvfrom)，而blocking IO只調用了一個system call (recvfrom)。但是，用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。

註意1：select函數返回結果中如果有文件可讀了，那麽進程就可以通過調用accept()或recv()來讓kernel將位於內核中準備到的數據copy到用戶區。

註意2: select的優勢在於可以處理多個連接，不適用於單個連接

Asynchronous I/O（異步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模型比較：

網絡I/O模型