Proactor 與 Reactor

Reactor和Proactor對比以及優缺點

兩種高效的事件處理模型：Reactor模式和Proactor模式

---

在高性能的I/O設計中，有兩個比較著名的模式Reactor和Proactor模式，其中Reactor模式用於同步I/O，而Proactor運用於異步I/O操做。

在比較這兩個模式以前，咱們首先的搞明白幾個概念，什麼是阻塞和非阻塞，什麼是同步和異步?

同步和異步是針對應用程序和內核的交互而言的，同步指的是用戶進程觸發IO操做並等待或者輪詢的去查看IO操做是否就緒，而異步是指用戶進程觸發IO操做之後便開始作本身的事情，而當IO操做已經完成的時候會獲得IO完成的通知（異步的特色就是通知）。

阻塞和非阻塞是針對於進程在訪問數據的時候，根據IO操做的就緒狀態來採起的不一樣方式，說白了是一種讀取或者寫入操做函數的實現方式，阻塞方式下讀取或者寫入函數將一直等待，而非阻塞方式下，讀取或者寫入函數會當即返回一個狀態值。

通常來講I/O模型能夠分爲：同步阻塞，同步非阻塞，異步阻塞，異步非阻塞IO

同步阻塞IO：在此種方式下，用戶進程在發起一個IO操做之後，必須等待IO操做的完成，只有當真正完成了IO操做之後，用戶進程才能運行。JAVA傳統的IO模型屬於此種方式！

同步非阻塞IO：在此種方式下，用戶進程發起一個IO操做之後邊可返回作其它事情，可是用戶進程須要時不時的詢問IO操做是否就緒，這就要求用戶進程不停的去詢問，從而引入沒必要要的CPU資源浪費。其中目前JAVA的NIO就屬於同步非阻塞IO。

異步阻塞IO：此種方式下是指應用發起一個IO操做之後，不等待內核IO操做的完成，等內核完成IO操做之後會通知應用程序，這其實就是同步和異步最關鍵的區別，同步必須等待或者主動的去詢問IO是否完成，那麼爲何說是阻塞的呢？由於此時是經過select系統調用來完成的，而select函數自己的實現方式是阻塞的，而採用select函數有個好處就是它能夠同時監聽多個文件句柄（若是從UNP的角度看，select屬於同步操做。由於select以後，進程還須要讀寫數據），從而提升系統的併發性！

異步非阻塞IO：在此種模式下，用戶進程只須要發起一個IO操做而後當即返回，等IO操做真正的完成之後，應用程序會獲得IO操做完成的通知，此時用戶進程只須要對數據進行處理就行了，不須要進行實際的IO讀寫操做，由於真正的IO讀取或者寫入操做已經由內核完成了。目前Java中尚未支持此種IO模型。

搞清楚了以上概念之後，咱們再回過頭來看看，Reactor模式和Proactor模式。

（其實阻塞與非阻塞均可以理解爲同步範疇下才有的概念，對於異步，就不會再去分阻塞非阻塞。對於用戶進程，接到異步通知後，就直接操做進程用戶態空間裏的數據好了。）

首先來看看Reactor模式，Reactor模式應用於同步I/O的場景。咱們分別以讀操做和寫操做爲例來看看Reactor中的具體步驟：

讀取操做：

1. 應用程序註冊讀就緒事件和相關聯的事件處理器
2. 事件分離器等待事件的發生
3. 當發生讀就緒事件的時候，事件分離器調用第一步註冊的事件處理器
4. 事件處理器首先執行實際的讀取操做，而後根據讀取到的內容進行進一步的處理

寫入操做相似於讀取操做，只不過第一步註冊的是寫就緒事件。

下面咱們來看看Proactor模式中讀取操做和寫入操做的過程：

讀取操做：

1. 應用程序初始化一個異步讀取操做，而後註冊相應的事件處理器，此時事件處理器不關注讀取就緒事件，而是關注讀取完成事件，這是區別於Reactor的關鍵。
2. 事件分離器等待讀取操做完成事件
3. 在事件分離器等待讀取操做完成的時候，操做系統調用內核線程完成讀取操做（異步IO都是操做系統負責將數據讀寫到應用傳遞進來的緩衝區供應用程序操做，操做系統扮演了重要角色），並將讀取的內容放入用戶傳遞過來的緩存區中。這也是區別於Reactor的一點，Proactor中，應用程序須要傳遞緩存區。
4. 事件分離器捕獲到讀取完成事件後，激活應用程序註冊的事件處理器，事件處理器直接從緩存區讀取數據，而不須要進行實際的讀取操做。

Proactor中寫入操做和讀取操做，只不過感興趣的事件是寫入完成事件。

從上面能夠看出，Reactor和Proactor模式的主要區別就是真正的讀取和寫入操做是有誰來完成的，Reactor中須要應用程序本身讀取或者寫入數據，而Proactor模式中，應用程序不須要進行實際的讀寫過程，它只須要從緩存區讀取或者寫入便可，操做系統會讀取緩存區或者寫入緩存區到真正的IO設備.

綜上所述，同步和異步是相對於應用和內核的交互方式而言的，同步須要主動去詢問，而異步的時候內核在IO事件發生的時候通知應用程序，而阻塞和非阻塞僅僅是系統在調用系統調用的時候函數的實現方式而已。

---

說到阻塞，首先得說說I/O等待。I/O等待是不可避免的，那麼既然有了等待，就會有阻塞，可是注意，咱們說的阻塞是指當前發起I/O操做的進程被阻塞。同步阻塞I/O即是指，當進程調用某些涉及I/O操做的系統調用或庫函數時，好比accept()(注意accept也算在了i/o操做)、send()、recv()等，進程便暫停下來，等待I/O操做完成再繼續運行。這是一種簡單而有效的I/O模型，它能夠和多進程結合起來有效的利用CPU資源，可是代價就是多進程的大量內存開銷。

同步阻塞：進程坐水,就不能燒粥 同步非阻塞：相似於用一個進程坐水，燒粥。while(true){if… if… }
好處就是一個進程處理多個i/o請求，劣勢就是須要不停的輪詢。

區別在於等不等待數據就緒。由於數據佔了等待的80%時間。同步非阻塞的優點就是一個進程裏同時處理多個I/O操做。

在同步阻塞I/O中，進程實際上等待的時間可能包括兩部分，一個是等待數據的就緒，另外一個是等待數據的複製，對於網絡I/O來講，前者的時間可能要更長一些。
與此不一樣的是,同步非阻塞I/O的調用不會等待數據的就緒，若是數據不可讀或者不可寫，它會當即返回告訴進程。

好比咱們使用非阻塞recv()接收網絡數據的時候，若是網卡緩衝區中沒有可接收的數據，函數就及時返回，告訴進程沒有數據可讀了。相比於阻塞I/O，這種非阻塞I/O結合反覆的輪詢來嘗試數據是否就緒，防止進程被阻塞，最大的好處便在於能夠在一個進程裏同時處理多個I/O操做。但正是因爲須要進程執行屢次的輪詢來查看數據是否就緒，這花費了大量的CPU時間，使得進程處於忙碌等待狀態。

非阻塞I/O通常只針對網絡I/O有效，咱們只要在socket的選項設置中使用O_NONBLOCK便可，這樣對於該socket的send()或recv()便採用非阻塞方式。若是服務器想要同時接收多個TCP鏈接的數據，就必須輪流對每一個socket調用接收數據的方法，好比recv()。無論這些socket有沒有能夠接收的數據，都要詢問一遍，假如大部分socket並無數據能夠接收，那麼進程便會浪費不少CPU時間用於檢查這些socket，這顯然不是咱們所但願看到的。

同步和異步，阻塞和非阻塞，有些混用，其實它們徹底不是一回事，並且它們修飾的對象也不相同。阻塞和非阻塞是指當進程訪問的數據若是還沒有就緒，進程是否須要等待，簡單說這至關於函數內部的實現區別，也就是未就緒時是直接返回仍是等待就緒；而同步和異步是指訪問數據的機制，同步通常指主動請求並等待I/O操做完畢的方式，當數據就緒後在讀寫的時候必須阻塞(區別就緒與讀寫二個階段，同步的讀寫必須阻塞)，異步則指主動請求數據後即可以繼續處理其它任務，隨後等待I/O，操做完畢的通知，這可使進程在數據讀寫時也不阻塞。(等待」通知」)

多數狀況下，Web服務器對這些請求採用基於隊列的自由競爭，經過多執行流(多進程或多線程)來充分佔 用CPU以及I/O資源，減小任何無辜的等待時間，這其中包括了不少種具體實現的併發策略，在實際應用中，特別是Web服務器，同時處理大量的文件描述符是必不可少的。多路I/O就緒通知的出現，提供了對大量文件描述符就緒檢查的高性能方案，它容許進程(好比電子屏,會聞到各個飯館作好飯菜的味道)經過一種方法來同時監視全部文件描述符，並能夠快速得到全部就緒的文件描述符，而後只針對這些文件描述符進行數據訪問。

回到買麪條的故事中，假如你不止買了一份麪條，還在其它幾個小吃店買了餃子、粥、餡餅等，由於一塊兒逛街的朋友看到你的麪條後也餓了。這些東西都須要時間來等待制做。在同步非阻塞I/O模型中，你要輪流不停的去各個小吃店詢問進度，痛苦不堪。如今引入多路I/O就緒通知後，小吃城管理處給大廳安裝了一塊電子屏幕,之後全部小吃店的食物作好後，都會顯示在屏幕上，這可真是個好消息，你只須要間隔性的看看大屏幕就能夠了，也許你還能夠同時逛逛附近的商店，在不遠處也能夠看到大屏幕。

多路就緒：一、強調多路； 二、只針對請求數據是否就緒，不針對I/O讀寫。epoll針對的是這樣的場景。select, epoll都只須要進程(我)被動接收到數據就緒(麪條)」通知」，符合異步的定義。 不須要一直在飯館等(同步阻塞)，或輪詢(同步非阻塞)。

---