原文：https://segmentfault.com/a/1190000007614502
一、閱前熱身
為了更加形象的說明同步異步、阻塞非阻塞，我們以小明去買奶茶為例。
1、同步與異步
①同步與異步的理解
同步與異步的重點在消息通知的方式上，也就是調用結果通知的方式。
-
同步當一個同步調用發出去后，調用者要一直等待調用結果的通知后，才能進行后續的執行
-
異步：當一個異步調用發出去后，調用者不能立即得到調用結果的返回。
異步調用，要想獲得結果，一般有兩種方式：
1、主動輪詢異步調用的結果;
2、被調用方通過callback來通知調用方調用結果。
②：生活實例
同步買奶茶：小明點單交錢，然后等着拿奶茶；異步買奶茶：小明點單交錢，店員給小明一個小票，等小明奶茶做好了，再來取。
異步買奶茶，小明要想知道奶茶是否做好了，有兩種方式：
1、小明主動去問店員，一會就去問一下：“奶茶做好了嗎？”...直到奶茶做好。
2、等奶茶做好了，店員喊一聲：“小明，奶茶好了！”，然后小明去取奶茶。
2、阻塞與非阻塞
①阻塞與非阻塞的理解
阻塞與非阻塞的重點在於進/線程等待消息時候的行為，也就是在等待消息的時候，當前進/線程是掛起狀態，還是非掛起狀態。
-
阻塞阻塞調用在發出去后，在消息返回之前，當前進/線程會被掛起，直到有消息返回，當前進/線程才會被激活.
-
非阻塞非阻塞調用在發出去后，不會阻塞當前進/線程，而會立即返回。
②：生活實例
阻塞買奶茶：小明點單交錢，干等着拿奶茶，什么事都不做；非阻塞買奶茶：小明點單交錢，等着拿奶茶，等的過程中，時不時刷刷微博、朋友圈...
3、總結
通過上面的分析，我們可以得知：
同步與異步，重點在於消息通知的方式;阻塞與非阻塞，重點在於等消息時候的行為。
所以，就有了下面4種組合方式
-
同步阻塞：小明在櫃台干等着拿奶茶；
-
同步非阻塞：小明在櫃台邊刷微博邊等着拿奶茶；
-
異步阻塞：小明拿着小票啥都不干，一直等着店員通知他拿奶茶；
-
異步非阻塞：小明拿着小票，刷着微博，等着店員通知他拿奶茶。
二、Nginx如何處理高並發
1、Apache面對高並發，為什么很無力？
Apache處理一個請求是同步阻塞的模式。
每到達一個請求，Apache都會去fork一個子進程去處理這個請求，直到這個請求處理完畢。
面對低並發，這種模式沒什么缺點，但是，面對高並發，就是這種模式的軟肋了。
-
1個客戶端占用1個進程，那么，進程數量有多少，並發處理能力就有多少，但操作系統可以創建的進程數量是有限的。
-
多進程就會有進程間的切換問題，而進程間的切換調度勢必會造成CPU的額外消耗。當進程數量達到成千上萬的時候，進程間的切換就占了CPU大部分的時間片，而真正進程的執行反而占了CPU的一小部分，這就得不償失了。
下面，舉例說明這2種場景是多進程模式的軟肋：
-
及時消息通知程序比如及時聊天程序，一台服務器可能要維持數十萬的連接(典型的C10K問題)，那么就要啟動數十萬的進程來維持。這顯然不可能。
-
調用外部Http接口時假設Apache啟動100個進程來處理請求，每個請求消耗100ms，那么這100個進程能提供1000qps。
但是，在我們調用外部Http接口時，比如QQ登錄、微博登錄，耗時較長，假設一個請求消耗10s，也就是1個進程1s處理0.1個請求，那么100個進程只能達到10qps，這樣的處理能力就未免太差了。
注：什么是C10K問題？網絡服務在處理數以萬計的客戶端連接時，往往出現效率低下甚至完全癱瘓，這被稱為C10K問題。（concurrent 10000 connection）
綜上，我們可以看出，Apache是同步阻塞的多進程模式，面對高並發等一些場景，是很蒼白的。
2、Nginx何以問鼎高並發？
傳統的服務器模型就是這樣，因為其同步阻塞的多進程模型，無法面對高並發。
那么，有沒有一種方式，可以讓我們在一個進程處理所有的並發I/O呢？
答案是有的，這就是I/O復用技術。
①、I/O復用是神馬？
最初級的I/O復用
所謂的I/O復用，就是多個I/O可以復用一個進程。
上面說的同步阻塞的多進程模型不適合處理高並發，那么，我們再來考慮非阻塞的方式。
采用非阻塞的模式，當一個連接過來時，我們不阻塞住，這樣一個進程可以同時處理多個連接了。
比如一個進程接受了10000個連接，這個進程每次從頭到尾的問一遍這10000個連接：“有I/O事件沒？有的話就交給我處理，沒有的話我一會再來問一遍。”
然后進程就一直從頭到尾問這10000個連接，如果這1000個連接都沒有I/O事件，就會造成CPU的空轉，並且效率也很低，不好不好。
升級版的I/O復用
上面雖然實現了基礎版的I/O復用，但是效率太低了。於是偉大的程序猿們日思夜想的去解決這個問題...終於！
我們能不能引入一個代理，這個代理可以同時觀察許多I/O流事件呢？
當沒有I/O事件的時候，這個進程處於阻塞狀態；當有I/O事件的時候，這個代理就去通知進程醒來？
於是，早期的程序猿們發明了兩個代理---select、poll。
select、poll代理的原理是這樣的：
當連接有I/O流事件產生的時候，就會去喚醒進程去處理。
但是進程並不知道是哪個連接產生的I/O流事件，於是進程就挨個去問：“請問是你有事要處理嗎？”......問了99999遍，哦，原來是第100000個進程有事要處理。那么，前面這99999次就白問了，白白浪費寶貴的CPU時間片了！痛哉，惜哉...
注:select與poll原理是一樣的，只不過select只能觀察1024個連接，poll可以觀察無限個連接。
上面看了，select、poll因為不知道哪個連接有I/O流事件要處理，性能也挺不好的。
那么，如果發明一個代理，每次能夠知道哪個連接有了I/O流事件，不就可以避免無意義的空轉了嗎？
於是，超級無敵、閃閃發光的epoll被偉大的程序員發明出來了。
epoll代理的原理是這樣的：
當連接有I/O流事件產生的時候，epoll就會去告訴進程哪個連接有I/O流事件產生，然后進程就去處理這個進程。
如此，多高效！
②、基於epoll的Nginx
有了epoll，理論上1個進程就可以無限數量的連接，而且無需輪詢，真正解決了c10k的問題。
Nginx是基於epoll的，異步非阻塞的服務器程序。自然，Nginx能夠輕松處理百萬級的並發連接，也就無可厚非了。
三、swoole如何處理高並發以及異步I/O的實現
1、swoole介紹
swoole是PHP的一個擴展。
簡單理解：swoole=異步I/O+網絡通信
PHPer可以基於swoole去實現過去PHP無法實現的功能。
具體請參考swoole官網：swoole官網
2、swoole如何處理高並發
①Reactor模型介紹
IO復用異步非阻塞程序使用經典的Reactor模型，Reactor顧名思義就是反應堆的意思，它本身不處理任何數據收發。只是可以監視一個socket(也可以是管道、eventfd、信號)句柄的事件變化。
注:什么是句柄？句柄英文為handler，可以形象的比喻為鍋柄、勺柄。也就是資源的唯一標識符、資源的ID。通過這個ID可以操作資源。
Reactor只是一個事件發生器，實際對socket句柄的操作，如connect/accept、send/recv、close是在callback中完成的。
②swoole的架構
swoole采用 多線程Reactor+多進程Worker
swoole的架構圖如下：
swoole的處理連接流程圖如下：
當請求到達時,swoole是這樣處理的：
請求到達 Main Reactor
| | Main Reactor根據Reactor的情況，將請求注冊給對應的Reactor (每個Reactor都有epoll。用來監聽客戶端的變化) | | 客戶端有變化時，交給worker來處理 | | worker處理完畢，通過進程間通信(比如管道、共享內存、消息隊列)發給對應的reactor。 | | reactor將響應結果發給相應的連接 | | 請求處理完成因為reactor基於epoll，所以每個reactor可以處理無數個連接請求。 如此，swoole就輕松的處理了高並發。
3、swoole如何實現異步I/O
基於上面的Swoole結構圖，我們看到swoole的worker進程有2種類型：
一種是 普通的worker進程，一種是 task worker進程。
worker進程是用來處理普通的耗時不是太長的請求；task worker進程用來處理耗時較長的請求，比如數據庫的I/O操作。
我們以異步Mysql舉例：
耗時較長的Mysql查詢進入worker
| | worker通過管道將這個請求交給taskworker來處理 | | worker再去處理其他請求 | | task worker處理完畢后，處理結果通過管道返回給worker | | worker 將結果返回給reactor | | reactor將結果返回給請求方如此，通過worker、task worker結合的方式，我們就實現了異步I/O。