1、定義
兩種I/O多路複用模式：Reactor和Proactor
一般地,I/O多路複用機制都依賴於一個事件多路分離器(Event Demultiplexer)。分離器對象可將來自事件源的I/O事件分離出來，並分發到對應的read/write事件處理器(Event Handler)。開發人員預先註冊需要處理的事件及其事件處理器（或回調函數）；事件分離器負責將請求事件傳遞給事件處理器。兩個與事件分離器有關的模式是Reactor和Proactor。Reactor模式採用同步IO，而Proactor採用異步IO。
在Reactor中，事件分離器負責等待文件描述符或socket爲讀寫操作準備就緒，然後將就緒事件傳遞給對應的處理器，最後由處理器負責完成實際的讀寫工作。
而在Proactor模式中，處理器–或者兼任處理器的事件分離器，只負責發起異步讀寫操作。IO操作本身由操作系統來完成。傳遞給操作系統的參數需要包括用戶定義的數據緩衝區地址和數據大小，操作系統才能從中得到寫出操作所需數據，或寫入從socket讀到的數據。事件分離器捕獲IO操作完成事件，然後將事件傳遞給對應處理器。比如，在windows上，處理器發起一個異步IO操作，再由事件分離器等待IOCompletion事件。典型的異步模式實現，都建立在操作系統支持異步API的基礎之上，我們將這種實現稱爲“系統級”異步或“真”異步，因爲應用程序完全依賴操作系統執行真正的IO工作。
舉個例子，將有助於理解Reactor與Proactor二者的差異，以讀操作爲例（類操作類似）。
在Reactor中實現讀：
- 註冊讀就緒事件和相應的事件處理器
- 事件分離器等待事件
- 事件到來，激活分離器，分離器調用事件對應的處理器。
- 事件處理器完成實際的讀操作，處理讀到的數據，註冊新的事件，然後返還控制權。
在Proactor中實現讀：
- 處理器發起異步讀操作（注意：操作系統必須支持異步IO）。在這種情況下，處理器無視IO就緒事件，它關注的是完成事件。
- 事件分離器等待操作完成事件
- 在分離器等待過程中，操作系統利用並行的內核線程執行實際的讀操作，並將結果數據存入用戶自定義緩衝區，最後通知事件分離器讀操作完成。
- 事件分離器呼喚處理器。
- 事件處理器處理用戶自定義緩衝區中的數據，然後啓動一個新的異步操作，並將控制權返回事件分離器。
可以看出，兩個模式的相同點，都是對某個IO事件的事件通知(即告訴某個模塊，這個IO操作可以進行或已經完成)。在結構上，兩者也有相同點：demultiplexor負責提交IO操作(異步)、查詢設備是否可操作(同步)，然後當條件滿足時，就回調handler；不同點在於，異步情況下(Proactor)，當回調handler時，表示IO操作已經完成；同步情況下(Reactor)，回調handler時，表示IO設備可以進行某個操作(can read or can write)。
2、通俗理解
使用Proactor框架和Reactor框架都可以極大的簡化網絡應用的開發，但它們的重點卻不同。
Reactor框架中用戶定義的操作是在實際操作之前調用的。比如你定義了操作是要向一個SOCKET寫數據，那麼當該SOCKET可以接收數據的時候，你的操作就會被調用；而Proactor框架中用戶定義的操作是在實際操作之後調用的。比如你定義了一個操作要顯示從SOCKET中讀入的數據，那麼當讀操作完成以後，你的操作纔會被調用。
Proactor和Reactor都是併發編程中的設計模式。在我看來，他們都是用於派發/分離IO操作事件的。這裏所謂的IO事件也就是諸如read/write的IO操作。”派發/分離”就是將單獨的IO事件通知到上層模塊。兩個模式不同的地方在於，Proactor用於異步IO，而Reactor用於同步IO。
3、備註
其實這兩種模式在ACE(網絡庫)中都有體現；如果要了解這兩種模式，可以參考ACE的源碼，ACE是開源的網絡框架，非常值得一學。。
關於Reactor和Proactor的區別
系統I/O 可分爲阻塞型， 非阻塞同步型以及非阻塞異步型。
阻塞型I/O意味着控制權只到調用操作結束了纔會回到調用者手裏。
非阻塞同步是會立即返回控制權給調用者的。調用者不需要等等，它從調用的函數獲取兩種結果：要麼此次調用成功進行了;要麼系統返回錯誤標識告訴調用者當前資源不可用，你再等等或者再試度看吧。比如read()操作， 如果當前socket無數據可讀，則立即返回EWOULBLOCK/EAGAIN，告訴調用read()者”數據還沒準備好，你稍後再試”。
非阻塞異步調用中，稍有不同。調用函數在立即返回時，還告訴調用者，這次請求已經開始了。系統會使用另外的資源或者線程來完成這次調用操作，並在完成的時候知會調用者（比如通過回調函數）。POSIX的aio_read()來說，調用它之後，函數立即返回，操作系統在後臺同時開始讀操作。即是將工作交給了內核去完成這個操作。
在以上三種IO形式中，非阻塞異步是性能最高、伸縮性最好的。
兩種IO多路複用方案:Reactor and Proactor
一般情況下，I/O 複用機制需要事件分享器(event demultiplexor)。 事件分享器的作用，即將那些讀寫事件源分發給各讀寫事件的處理者，就像送快遞的在樓下喊: 誰的什麼東西送了， 快來拿吧。開發人員在開始的時候需要在分享器那裏註冊感興趣的事件，並提供相應的處理者(event handlers)，或者是回調函數; 事件分享器在適當的時候會將請求的事件分發給這些handler或者回調函數。
涉及到事件分享器的兩種模式稱爲：Reactor and Proactor。 Reactor模式是基於同步I/O的，而Proactor模式是和異步I/O相關的。 在Reactor模式中，事件分離者等待某個事件或者可應用或個操作的狀態發生（比如文件描述符可讀寫，或者是socket可讀寫），事件分離者就把這個事件傳給事先註冊的事件處理函數或者回調函數，由後者來做實際的讀寫操作。
而在Proactor模式中，事件處理者(或者代由事件分離者發起)直接發起一個異步讀寫操作(相當於請求)，而實際的工作是由操作系統來完成的。發起時，需要提供的參數包括用於存放讀到數據的緩存區，讀的數據大小，或者用於存放外發數據的緩存區，以及這個請求完後的回調函數等信息。事件分離者得知了這個請求，它默默等待這個請求的完成，然後轉發完成事件給相應的事件處理者或者回調。這種異步模式的典型實現是基於操作系統底層異步API的，所以我們可稱之爲“系統級別”的或者“真正意義上”的異步，因爲具體的讀寫是由操作系統代勞的。
舉另外個例子來更好地理解Reactor與Proactor兩種模式的區別。這裏我們只關注read操作，因爲write操作也是差不多的。下面是Reactor的做法：
某個事件處理者宣稱它對某個socket上的讀事件很感興趣;
事件分離者等着這個事件的發生;
當事件發生了，事件分離器被喚醒，這負責通知先前那個事件處理者;
事件處理者收到消息，於是去那個socket上讀數據了。 如果需要，它再次宣稱對這個socket上的讀事件感興趣，一直重複上面的步驟;
下面再來看看真正意義的異步模式Proactor是如何做的：
事件處理者直接投遞發一個寫操作(當然，操作系統必須支持這個異步操作)。 這個時候，事件處理者根本不關心讀事件，它只管發這麼個請求，它魂牽夢縈的是這個寫操作的完成事件。這個處理者很拽，發個命令就不管具體的事情了，只等着別人（系統）幫他搞定的時候給他回個話。
事件分離者等着這個讀事件的完成(比較下與Reactor的不同);
當事件分離者默默等待完成事情到來的同時，操作系統已經在一邊開始幹活了，它從目標讀取數據，放入用戶提供的緩存區中，最後通知事件分離者，這個事情我搞完了;
事件分享者通知之前的事件處理者: 你吩咐的事情搞定了;
事件處理者這時會發現想要讀的數據已經乖乖地放在他提供的緩存區中，想怎麼處理都行了。如果有需要，事件處理者還像之前一樣發起另外一個寫操作，和上面的幾個步驟一樣。
標準的經典的 Reactor模式:
步驟 1) 等待事件 (Reactor 的工作)
步驟 2) 發”已經可讀”事件發給事先註冊的事件處理者或者回調 ( Reactor 要做的)
步驟 3) 讀數據 (用戶代碼要做的)
步驟 4) 處理數據 (用戶代碼要做的)
模擬的Proactor模式:
步驟 1) 等待事件 (Proactor 的工作)
步驟 2) 讀數據(看，這裏變成成了讓 Proactor 做這個事情)
步驟 3) 把數據已經準備好的消息給用戶處理函數，即事件處理者(Proactor 要做的)
步驟 4) 處理數據 (用戶代碼要做的)
在沒有底層異步I/O API支持的操作系統，這種方法可以幫我們隱藏掉socket接口的差異(無論是性能還是其它)， 提供一個完全可用的統一“異步接口”。這樣我們就可以開發真正平臺獨立的通用接口了。
那麼，綜上所述，這兩者的區別是什麼呢？
簡單直觀的理解：
1、Reactor模式是等待關心的動作的發生後，將如何處理這個動作的後續交給了用戶態的應用本身來處理，Reactor的事件分享器只關心事件的發生，其它的就完全交給應用程序來處理了；而Proactor模式則是隻關心由操作系統(內核)完成異步非阻塞的操作後返回的結果；
2、Proactor場景中只能夠使用異步非阻塞的syscall(系統調用)，而Reactor的場景中更多地是使用非阻塞同步的syscall(系統調用)；
IO - 同步，異步，阻塞，非阻塞概念的請先看下這個科普：
同步(synchronous) IO和異步(asynchronous) IO，阻塞(blocking) IO和非阻塞(non-blocking)IO分別是什麼，到底有什麼區別?這個問題其實不同的人給出的答案都可能不同，比如wiki，就認爲 asynchronous IO和non-blocking IO是一個東西。這其實是因爲不同的人的知識背景不同，並且在討論這個問題的時候上下文(context)也不相同。所以，爲了更好的回答這個問題，我先限定一下本文的上下文。
本文討論的背景是Linux環境下的network IO。
本文最重要的參考文獻是Richard Stevens的“UNIX® Network Programming Volume 1, Third Edition: The Sockets Networking ”，6.2節“I/O Models ”，Stevens在這節中詳細說明了各種IO的特點和區別，如果英文夠好的話，推薦直接閱讀。Stevens的文風是有名的深入淺出，所以不用擔心看不懂。本文中的流程圖也是截取自參考文獻。
Stevens在文章中一共比較了五種IO Model：
blocking IO
nonblocking IO
IO multiplexing
signal driven IO
asynchronous IO
由於signal driven IO在實際中並不常用，所以我這隻提及剩下的四種IO Model。
再說一下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
在linux中，默認情況下所有的socket都是blocking，一個典型的讀操作流程大概是這樣：
當用戶進程調用了recvfrom這個系統調用，kernel就開始了IO的第一個階段：準備數據。對於network io來說，很多時候數據在一開始還沒有到達(比如，還沒有收到一個完整的UDP包)，這個時候kernel就要等待足夠的數據到來。而在用戶進程這邊，整個進程會被阻塞。當kernel一直等到數據準備好了，它就會將數據從kernel中拷貝到用戶內存，然後kernel返回結果，用戶進程才解除 block的狀態，重新運行起來。
所以，blocking IO的特點就是在IO執行的兩個階段都被block了。
non-blocking IO
linux下，可以通過設置socket使其變爲non-blocking。當對一個non-blocking socket執行讀操作時，流程是這個樣子：
從圖中可以看出，當用戶進程發出read操作時，如果kernel中的數據還沒有準備好，那麼它並不會block用戶進程，而是立刻返回一個 error。從用戶進程角度講 ，它發起一個read操作後，並不需要等待，而是馬上就得到了一個結果。用戶進程判斷結果是一個error時，它就知道數據還沒有準備好，於是它可以再次發送read操作。一旦kernel中的數據準備好了，並且又再次收到了用戶進程的system call，那麼它馬上就將數據拷貝到了用戶內存，然後返回。
所以，用戶進程其實是需要不斷的主動詢問kernel數據好了沒有。
IO multiplexing
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。
Asynchronous I/O
linux下的asynchronous IO其實用得很少。先看一下它的流程：
用戶進程發起read操作之後，立刻就可以開始去做其它的事。而另一方面，從kernel的角度，當它受到一個asynchronous read之後，首先它會立刻返回，所以不會對用戶進程產生任何block。然後，kernel會等待數據準備完成，然後將數據拷貝到用戶內存，當這一切都完成之後，kernel會給用戶進程發送一個signal，告訴它read操作完成了。
到目前爲止，已經將四個IO Model都介紹完了。現在回過頭來回答最初的那幾個問題：blocking和non-blocking的區別在哪，synchronous IO和asynchronous IO的區別在哪。
先回答最簡單的這個：blocking vs non-blocking。前面的介紹中其實已經很明確的說明了這兩者的區別。調用blocking IO會一直block住對應的進程直到操作完成，而non-blocking IO在kernel還準備數據的情況下會立刻返回。
在說明synchronous IO和asynchronous IO的區別之前，需要先給出兩者的定義。Stevens給出的定義(其實是POSIX的定義)是這樣子的：
A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes;
An asynchronous I/O operation does not cause the requesting process to be blocked;
兩者的區別就在於synchronous IO做”IO operation”的時候會將process阻塞。按照這個定義，之前所述的blocking IO，non-blocking IO，IO multiplexing都屬於synchronous IO。有人可能會說，non-blocking IO並沒有被block啊。這裏有個非常“狡猾”的地方，定義中所指的”IO operation”是指真實的IO操作，就是例子中的recvfrom這個system call。non-blocking IO在執行recvfrom這個system call的時候，如果kernel的數據沒有準備好，這時候不會block進程。但是，當kernel中數據準備好的時候，recvfrom會將數據從 kernel拷貝到用戶內存中，這個時候進程是被block了，在這段時間內，進程是被block的。而asynchronous IO則不一樣，當進程發起IO 操作之後，就直接返回再也不理睬了，直到kernel發送一個信號，告訴進程說IO完成。在這整個過程中，進程完全沒有被block。
各個IO Model的比較如圖所示：
經過上面的介紹，會發現non-blocking IO和asynchronous IO的區別還是很明顯的。在non-blocking IO中，雖然進程大部分時間都不會被block，但是它仍然要求進程去主動的check，並且當數據準備完成以後，也需要進程主動的再次調用 recvfrom來將數據拷貝到用戶內存。而asynchronous IO則完全不同。它就像是用戶進程將整個IO操作交給了他人(kernel)完成，然後他人做完後發信號通知。在此期間，用戶進程不需要去檢查IO操作的狀態，也不需要主動的去拷貝數據。
最後，再舉幾個不是很恰當的例子來說明這四個IO Model:
有A，B，C，D四個人在釣魚：
A用的是最老式的魚竿，所以呢，得一直守着，等到魚上鉤了再拉桿;
B的魚竿有個功能，能夠顯示是否有魚上鉤，所以呢，B就和旁邊的MM聊天，隔會再看看有沒有魚上鉤，有的話就迅速拉桿;
C用的魚竿和B差不多，但他想了一個好辦法，就是同時放好幾根魚竿，然後守在旁邊，一旦有顯示說魚上鉤了，它就將對應的魚竿拉起來;
D是個有錢人，乾脆僱了一個人幫他釣魚，一旦那個人把魚釣上來了，就給D發個短信。