原文鏈接：https://segmentfault.com/a/1190000007614502
一衬横、閱前熱身
為了更加形象的說明同步異步、阻塞非阻塞终蒂，我們以小明去買奶茶為例蜂林。
1、同步與異步
①同步與異步的理解
同步與異步的重點在消息通知的方式上拇泣，也就是調(diào)用結(jié)果通知的方式噪叙。
同步
當一個同步調(diào)用發(fā)出去后，調(diào)用者要一直等待調(diào)用結(jié)果的通知后霉翔，才能進行后續(xù)的執(zhí)行
異步：
當一個異步調(diào)用發(fā)出去后睁蕾，調(diào)用者不能立即得到調(diào)用結(jié)果的返回。
異步調(diào)用，要想獲得結(jié)果子眶，一般有兩種方式：
1瀑凝、主動輪詢異步調(diào)用的結(jié)果;
2、被調(diào)用方通過callback來通知調(diào)用方調(diào)用結(jié)果臭杰。
②：生活實例
同步買奶茶：小明點單交錢粤咪，然后等著拿奶茶；
異步買奶茶：小明點單交錢渴杆，店員給小明一個小票寥枝，等小明奶茶做好了，再來取将塑。
異步買奶茶脉顿，小明要想知道奶茶是否做好了，有兩種方式：
1点寥、小明主動去問店員艾疟，一會就去問一下：“奶茶做好了嗎？”...直到奶茶做好敢辩。
2蔽莱、等奶茶做好了，店員喊一聲：“小明戚长，奶茶好了盗冷！”，然后小明去取奶茶同廉。
2仪糖、阻塞與非阻塞
①阻塞與非阻塞的理解
阻塞與非阻塞的重點在于進/線程等待消息時候的行為，也就是在等待消息的時候迫肖，當前進/線程是掛起狀態(tài)锅劝，還是非掛起狀態(tài)。
阻塞
阻塞調(diào)用在發(fā)出去后蟆湖，在消息返回之前故爵，當前進/線程會被掛起，直到有消息返回隅津，當前進/線程才會被激活.
非阻塞
非阻塞調(diào)用在發(fā)出去后诬垂，不會阻塞當前進/線程，而會立即返回伦仍。
②：生活實例
阻塞買奶茶：小明點單交錢结窘，干等著拿奶茶，什么事都不做充蓝；
非阻塞買奶茶：小明點單交錢隧枫，等著拿奶茶，等的過程中，時不時刷刷微博悠垛、朋友圈...
3线定、總結(jié)
通過上面的分析，我們可以得知：
同步與異步确买，重點在于消息通知的方式;阻塞與非阻塞斤讥，重點在于等消息時候的行為。
所以湾趾，就有了下面4種組合方式
同步阻塞：小明在柜臺干等著拿奶茶芭商；
同步非阻塞：小明在柜臺邊刷微博邊等著拿奶茶；
異步阻塞：小明拿著小票啥都不干搀缠，一直等著店員通知他拿奶茶铛楣；
異步非阻塞：小明拿著小票，刷著微博艺普，等著店員通知他拿奶茶簸州。
二、Nginx如何處理高并發(fā)
1歧譬、Apache面對高并發(fā)岸浑，為什么很無力？
Apache處理一個請求是同步阻塞的模式瑰步。
每到達一個請求矢洲，Apache都會去fork一個子進程去處理這個請求，直到這個請求處理完畢缩焦。
面對低并發(fā)读虏，這種模式?jīng)]什么缺點，但是袁滥，面對高并發(fā)盖桥，就是這種模式的軟肋了。
1個客戶端占用1個進程呻拌，那么葱轩，進程數(shù)量有多少睦焕，并發(fā)處理能力就有多少藐握，但操作系統(tǒng)可以創(chuàng)建的進程數(shù)量是有限的。
多進程就會有進程間的切換問題垃喊，而進程間的切換調(diào)度勢必會造成CPU的額外消耗猾普。當進程數(shù)量達到成千上萬的時候，進程間的切換就占了CPU大部分的時間片本谜，而真正進程的執(zhí)行反而占了CPU的一小部分初家，這就得不償失了。
下面，舉例說明這2種場景是多進程模式的軟肋：
及時消息通知程序
比如及時聊天程序溜在，一臺服務器可能要維持數(shù)十萬的連接(典型的C10K問題)陌知，那么就要啟動數(shù)十萬的進程來維持。這顯然不可能掖肋。
調(diào)用外部Http接口時
假設Apache啟動100個進程來處理請求仆葡，每個請求消耗100ms，那么這100個進程能提供1000qps志笼。
但是沿盅，在我們調(diào)用外部Http接口時，比如QQ登錄纫溃、微博登錄腰涧，耗時較長，假設一個請求消耗10s紊浩，也就是1個進程1s處理0.1個請求窖铡，那么100個進程只能達到10qps，這樣的處理能力就未免太差了坊谁。
注：什么是C10K問題万伤？
網(wǎng)絡服務在處理數(shù)以萬計的客戶端連接時，往往出現(xiàn)效率低下甚至完全癱瘓呜袁，這被稱為C10K問題敌买。（concurrent 10000 connection）
綜上，我們可以看出阶界，Apache是同步阻塞的多進程模式虹钮，面對高并發(fā)等一些場景，是很蒼白的膘融。
2芙粱、Nginx何以問鼎高并發(fā)？
傳統(tǒng)的服務器模型就是這樣氧映，因為其同步阻塞的多進程模型春畔，無法面對高并發(fā)。
那么岛都，有沒有一種方式律姨，可以讓我們在一個進程處理所有的并發(fā)I/O呢？
答案是有的臼疫，這就是I/O復用技術择份。
①、I/O復用是神馬烫堤？
最初級的I/O復用
所謂的I/O復用荣赶，就是多個I/O可以復用一個進程凤价。
上面說的同步阻塞的多進程模型不適合處理高并發(fā)，那么拔创，我們再來考慮非阻塞的方式利诺。
采用非阻塞的模式，當一個連接過來時剩燥，我們不阻塞住立轧，這樣一個進程可以同時處理多個連接了。
比如一個進程接受了10000個連接躏吊，這個進程每次從頭到尾的問一遍這10000個連接：“有I/O事件沒氛改？有的話就交給我處理，沒有的話我一會再來問一遍比伏。”
然后進程就一直從頭到尾問這10000個連接胜卤，如果這1000個連接都沒有I/O事件，就會造成CPU的空轉(zhuǎn)赁项，并且效率也很低葛躏，不好不好。
升級版的I/O復用
上面雖然實現(xiàn)了基礎版的I/O復用悠菜，但是效率太低了。于是偉大的程序猿們?nèi)账家瓜氲娜ソ鉀Q這個問題...終于摩窃！
我們能不能引入一個代理，這個代理可以同時觀察許多I/O流事件呢蒂秘？
當沒有I/O事件的時候，這個進程處于阻塞狀態(tài)撇贺；當有I/O事件的時候显熏，這個代理就去通知進程醒來喘蟆？
于是蕴轨，早期的程序猿們發(fā)明了兩個代理---select、poll棘脐。
select、poll代理的原理是這樣的：
當連接有I/O流事件產(chǎn)生的時候屈梁，就會去喚醒進程去處理。
但是進程并不知道是哪個連接產(chǎn)生的I/O流事件构哺，于是進程就挨個去問：“請問是你有事要處理嗎？”......問了99999遍旗扑，哦，原來是第100000個進程有事要處理袱衷。那么致燥，前面這99999次就白問了嫌蚤，白白浪費寶貴的CPU時間片了脱吱！痛哉续捂，惜哉...
注:select與poll原理是一樣的牙瓢，只不過select只能觀察1024個連接一罩，poll可以觀察無限個連接。
上面看了汉嗽，select、poll因為不知道哪個連接有I/O流事件要處理，性能也挺不好的撰筷。
那么，如果發(fā)明一個代理关筒，每次能夠知道哪個連接有了I/O流事件，不就可以避免無意義的空轉(zhuǎn)了嗎袍榆？
于是碉纳，超級無敵、閃閃發(fā)光的epoll被偉大的程序員發(fā)明出來了房资。
epoll代理的原理是這樣的：
當連接有I/O流事件產(chǎn)生的時候轰异，epoll就會去告訴進程哪個連接有I/O流事件產(chǎn)生，然后進程就去處理這個進程暑始。
如此搭独，多高效！
②廊镜、基于epoll的Nginx
有了epoll牙肝，理論上1個進程就可以無限數(shù)量的連接，而且無需輪詢嗤朴，真正解決了c10k的問題配椭。
Nginx是基于epoll的，異步非阻塞的服務器程序雹姊。自然股缸，Nginx能夠輕松處理百萬級的并發(fā)連接，也就無可厚非了吱雏。
三乓序、swoole如何處理高并發(fā)以及異步I/O的實現(xiàn)
1、swoole介紹
swoole是PHP的一個擴展坎背。
簡單理解：swoole=異步I/O+網(wǎng)絡通信
PHPer可以基于swoole去實現(xiàn)過去PHP無法實現(xiàn)的功能替劈。
具體請參考swoole官網(wǎng)：swoole官網(wǎng)
2、swoole如何處理高并發(fā)
①Reactor模型介紹
IO復用異步非阻塞程序使用經(jīng)典的Reactor模型得滤，Reactor顧名思義就是反應堆的意思陨献，它本身不處理任何數(shù)據(jù)收發(fā)。只是可以監(jiān)視一個socket(也可以是管道懂更、eventfd眨业、信號)句柄的事件變化急膀。
注:什么是句柄？句柄英文為handler龄捡，可以形象的比喻為鍋柄卓嫂、勺柄。也就是資源的唯一標識符聘殖、資源的ID晨雳。通過這個ID可以操作資源。
Reactor只是一個事件發(fā)生器奸腺，實際對socket句柄的操作餐禁，如connect/accept、send/recv突照、close是在callback中完成的帮非。
②swoole的架構(gòu)
swoole采用?多線程Reactor+多進程Worker
swoole的架構(gòu)圖如下：
swoole的處理連接流程圖如下：
當請求到達時,swoole是這樣處理的：
請求到達 Main Reactor|
? ? ? ? |Main Reactor根據(jù)Reactor的情況，將請求注冊給對應的Reactor(每個Reactor都有epoll讹蘑。用來監(jiān)聽客戶端的變化)|
? ? ? ? |客戶端有變化時末盔，交給worker來處理|
? ? ? ? |worker處理完畢，通過進程間通信(比如管道座慰、共享內(nèi)存陨舱、消息隊列)發(fā)給對應的reactor。|
? ? ? ? |reactor將響應結(jié)果發(fā)給相應的連接|
? ? ? ? |請求處理完成
因為reactor基于epoll角骤，所以每個reactor可以處理無數(shù)個連接請求隅忿。
如此，swoole就輕松的處理了高并發(fā)邦尊。
3背桐、swoole如何實現(xiàn)異步I/O
基于上面的Swoole結(jié)構(gòu)圖，我們看到swoole的worker進程有2種類型：
一種是 普通的worker進程蝉揍，一種是 task worker進程链峭。
worker進程是用來處理普通的耗時不是太長的請求；
task worker進程用來處理耗時較長的請求又沾，比如數(shù)據(jù)庫的I/O操作弊仪。
我們以異步Mysql舉例：
耗時較長的Mysql查詢進入worker
????????????|
worker通過管道將這個請求交給taskworker來處理
? ? ? ? ? ? |
worker再去處理其他請求
? ? ? ? ? ? |
task worker處理完畢后，處理結(jié)果通過管道返回給worker
? ? ? ? ? ? |
worker 將結(jié)果返回給reactor
? ? ? ? ? ? |
reactor將結(jié)果返回給請求方
如此杖刷，通過worker励饵、task worker結(jié)合的方式，我們就實現(xiàn)了異步I/O滑燃。
