事件驅動模型和異步IO多路複用

事件驅動模型

協程：遇到IO操作就切換。 
但什麼時候切回去呢？怎麼確定IO操作完了？

 

很多程序員可能會考慮使用“線程池”或“連接池”。“線程池”旨在減少創建和銷燬線程的頻率，其維持一定合理數量的線程，並讓空閒的線程重新承擔新的執行任務。“連接池”維持連接的緩存池，儘量重用已有的連接、減少創建和關閉連接的頻率。

這兩種技術都可以很好的降低系統開銷，都被廣泛應用很多大型系統，如websphere、tomcat和各種數據庫等。但是，“線程池”和“連接池”技術也只是在一定程度上緩解了頻繁調用IO接口帶來的資源佔用。而且，所謂“池”始終有其上限，當請求大大超過上限時，“池”構成的系統對外界的響應並不比沒有池的時候效果好多少。所以使用“池”必須考慮其面臨的響應規模，並根據響應規模調整“池”的大小。
對應上例中的所面臨的可能同時出現的上千甚至上萬次的客戶端請求，“線程池”或“連接池”或許可以緩解部分壓力，但是不能解決所有問題。總之，多線程模型可以方便高效的解決小規模的服務請求，但面對大規模的服務請求，多線程模型也會遇到瓶頸，可以用非阻塞接口來嘗試解決這個問題

 

傳統的編程是如下線性模式的：

開始--->代碼塊A--->代碼塊B--->代碼塊C--->代碼塊D--->......--->結束

每一個代碼塊裏是完成各種各樣事情的代碼，但編程者知道代碼塊A,B,C,D...的執行順序，唯一能夠改變這個流程的是數據。輸入不同的數據，根據條件語句判斷，流程或許就改爲A--->C--->E...--->結束。每一次程序運行順序或許都不同，但它的控制流程是由輸入數據和你編寫的程序決定的。如果你知道這個程序當前的運行狀態（包括輸入數據和程序本身），那你就知道接下來甚至一直到結束它的運行流程。

 對於事件驅動型程序模型，它的流程大致如下：

開始--->初始化--->等待

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

一、事件驅動模型介紹

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

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

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

論事件驅動模型 

在UI編程中，常常要對鼠標點擊進行相應，首先如何獲得鼠標點擊呢？ 兩種方式：

1創建一個線程循環檢測是否有鼠標點擊

      那麼這個方式有以下幾個缺點：

1. CPU資源浪費，可能鼠標點擊的頻率非常小，但是掃描線程還是會一直循環檢測，這會造成很多的CPU資源浪費；如果掃描鼠標點擊的接口是阻塞的呢？
2. 如果是堵塞的，又會出現下面這樣的問題，如果我們不但要掃描鼠標點擊，還要掃描鍵盤是否按下，由於掃描鼠標時被堵塞了，那麼可能永遠不會去掃描鍵盤；
3. 如果一個循環需要掃描的設備非常多，這又會引來響應時間的問題； 
   所以，該方式是非常不好的。

2 就是事件驅動模型 

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

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

 

事件驅動編程是一種編程範式，這裏程序的執行流由外部事件來決定。它的特點是包含一個事件循環，當外部事件發生時使用回調機制來觸發相應的處理。另外兩種常見的編程範式是（單線程）同步以及多線程編程。 
　
讓我們用例子來比較和對比一下單線程、多線程以及事件驅動編程模型。下圖展示了隨着時間的推移，這三種模式下程序所做的工作。這個程序有3個任務需要完成，每個任務都在等待I/O操作時阻塞自身。阻塞在I/O操作上所花費的時間已經用灰色框標示出來了。 

最初的問題：怎麼確定IO操作完了切回去呢？通過回調函數 

1.要理解事件驅動和程序，就需要與非事件驅動的程序進行比較。實際上，現代的程序大多是事件驅動的，比如多線程的程序，肯定是事件驅動的。早期則存在許多非事件驅動的程序，這樣的程序，在需要等待某個條件觸發時，會不斷地檢查這個條件，直到條件滿足，這是很浪費cpu時間的。而事件驅動的程序，則有機會釋放cpu從而進入睡眠態（注意是有機會，當然程序也可自行決定不釋放cpu），當事件觸發時被操作系統喚醒，這樣就能更加有效地使用cpu.
2.再說什麼是事件驅動的程序。一個典型的事件驅動的程序，就是一個死循環，並以一個線程的形式存在，這個死循環包括兩個部分，第一個部分是按照一定的條件接收並選擇一個要處理的事件，第二個部分就是事件的處理過程。程序的執行過程就是選擇事件和處理事件，而當沒有任何事件觸發時，程序會因查詢事件隊列失敗而進入睡眠狀態，從而釋放cpu。
3.事件驅動的程序，必定會直接或者間接擁有一個事件隊列，用於存儲未能及時處理的事件。
4.事件驅動的程序的行爲，完全受外部輸入的事件控制，所以，事件驅動的系統中，存在大量這種程序，並以事件作爲主要的通信方式。
5.事件驅動的程序，還有一個最大的好處，就是可以按照一定的順序處理隊列中的事件，而這個順序則是由事件的觸發順序決定的，這一特性往往被用於保證某些過程的原子化。
6.目前windows,linux,nucleus,vxworks都是事件驅動的，只有一些單片機可能是非事件驅動的。

注意，事件驅動的監聽事件是由操作系統調用的cpu來完成的

在單線程同步模型中，任務按照順序執行。如果某個任務因爲I/O而阻塞，其他所有的任務都必須等待，直到它完成之後它們才能依次執行。這種明確的執行順序和串行化處理的行爲是很容易推斷得出的。如果任務之間並沒有互相依賴的關係，但仍然需要互相等待的話這就使得程序不必要的降低了運行速度。

在多線程版本中，這3個任務分別在獨立的線程中執行。這些線程由操作系統來管理，在多處理器系統上可以並行處理，或者在單處理器系統上交錯執行。這使得當某個線程阻塞在某個資源的同時其他線程得以繼續執行。與完成類似功能的同步程序相比，這種方式更有效率，但程序員必須寫代碼來保護共享資源，防止其被多個線程同時訪問。多線程程序更加難以推斷，因爲這類程序不得不通過線程同步機制如鎖、可重入函數、線程局部存儲或者其他機制來處理線程安全問題，如果實現不當就會導致出現微妙且令人痛不欲生的bug。

在事件驅動版本的程序中，3個任務交錯執行，但仍然在一個單獨的線程控制中。當處理I/O或者其他昂貴的操作時，註冊一個回調到事件循環中，然後當I/O操作完成時繼續執行。回調描述了該如何處理某個事件。事件循環輪詢所有的事件，當事件到來時將它們分配給等待處理事件的回調函數。這種方式讓程序儘可能的得以執行而不需要用到額外的線程。事件驅動型程序比多線程程序更容易推斷出行爲，因爲程序員不需要關心線程安全問題。

當我們面對如下的環境時，事件驅動模型通常是一個好的選擇：

1. 程序中有許多任務，而且…
2. 任務之間高度獨立（因此它們不需要互相通信，或者等待彼此）而且…
3. 在等待事件到來時，某些任務會阻塞。

當應用程序需要在任務間共享可變的數據時，這也是一個不錯的選擇，因爲這裏不需要採用同步處理。

網絡應用程序通常都有上述這些特點，這使得它們能夠很好的契合事件驅動編程模型。

 

IO多路複用

概念說明

 

在進行解釋之前，首先要說明幾個概念：

 

1. 用戶空間和內核空間
2. 進程切換
3. 進程的阻塞
4. 文件描述符
5. 緩存 I/O

 

用戶空間與內核空間

 

現在操作系統都是採用虛擬存儲器，那麼對32位操作系統而言，它的尋址空間（虛擬存儲空間）爲4G（2的32次方）。 
操作系統的核心是內核，獨立於普通的應用程序，可以訪問受保護的內存空間，也有訪問底層硬件設備的所有權限。 
爲了保證用戶進程不能直接操作內核（kernel），保證內核的安全，操心繫統將虛擬空間劃分爲兩部分，一部分爲內核空間，一部分爲用戶空間。 
針對linux操作系統而言，將最高的1G字節（從虛擬地址0xC0000000到0xFFFFFFFF），供內核使用，稱爲內核空間，而將較低的3G字節（從虛擬地址0x00000000到0xBFFFFFFF），供各個進程使用，稱爲用戶空間。 

 

進程切換

 

爲了控制進程的執行，內核必須有能力掛起正在CPU上運行的進程，並恢復以前掛起的某個進程的執行。這種行爲被稱爲進程切換，這種切換是由操作系統來完成的。因此可以說，任何進程都是在操作系統內核的支持下運行的，是與內核緊密相關的。 
從一個進程的運行轉到另一個進程上運行，這個過程中經過下面這些變化：

 

保存處理機上下文，包括程序計數器和其他寄存器。

 

更新PCB信息。

 

把進程的PCB移入相應的隊列，如就緒、在某事件阻塞等隊列。

 

選擇另一個進程執行，並更新其PCB。

 

更新內存管理的數據結構。

 

恢復處理機上下文。 
注：總而言之就是很耗資源的

 

進程的阻塞

 

正在執行的進程，由於期待的某些事件未發生，如請求系統資源失敗、等待某種操作的完成、新數據尚未到達或無新工作做等，則由系統自動執行阻塞原語(Block)，使自己由運行狀態變爲阻塞狀態。可見，進程的阻塞是進程自身的一種主動行爲，也因此只有處於運行態的進程（獲得CPU），纔可能將其轉爲阻塞狀態。當進程進入阻塞狀態，是不佔用CPU資源的。

 

文件描述符fd

 

文件描述符（File descriptor）是計算機科學中的一個術語，是一個用於表述指向文件的引用的抽象化概念。 
文件描述符在形式上是一個非負整數。實際上，它是一個索引值，指向內核爲每一個進程所維護的該進程打開文件的記錄表。當程序打開一個現有文件或者創建一個新文件時，內核向進程返回一個文件描述符。在程序設計中，一些涉及底層的程序編寫往往會圍繞着文件描述符展開。但是文件描述符這一概念往往只適用於UNIX、Linux這樣的操作系統。

 

緩存 I/O

 

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

 

思考：爲什麼數據一定要先到內核區，直接到用戶內存不是更直接嗎？
緩存 I/O 的缺點： 

 

數據在傳輸過程中需要在應用程序地址空間和內核進行多次數據拷貝操作，這些數據拷貝操作所帶來的 CPU 以及內存開銷是非常大的。

 

 

IO模式

 

對於一次IO訪問（以read舉例），數據會先被拷貝到操作系統內核的緩衝區中，然後纔會從操作系統內核的緩衝區拷貝到應用程序的地址空間。所以說，當一個read操作發生時，它會經歷兩個階段：
1. 等待數據準備 (Waiting for the data to be ready)  等待客戶端連接(conn ,addr 客戶端的每一個連接就是一個socket對象)
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。

 

blocking IO （阻塞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的圖其實並沒有太大的不同，事實上，還更差一些。因爲這裏需要使用兩個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。

 

異步 I/O（asynchronous IO）

inux下的asynchronous IO其實用得很少。先看一下它的流程：

用戶進程發起read操作之後，立刻就可以開始去做其它的事。而另一方面，從kernel的角度，當它受到一個asynchronous read之後，首先它會立刻返回，所以不會對用戶進程產生任何block。然後，kernel會等待數據準備完成，然後將數據拷貝到用戶內存，當這一切都完成之後，kernel會給用戶進程發送一個signal，告訴它read操作完成了。

 

sellect、poll、epoll三者的區別  

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()時便得到通知。