[TOC]

閱前熱身

為了更加形象的說(shuō)明同步/異步隘马、阻塞/非阻塞，我們以小明去買(mǎi)奶茶為例庐舟。

同步與異步

• 同步：當(dāng)一個(gè)同步調(diào)用發(fā)出去后队贱，調(diào)用者要一直等待調(diào)用結(jié)果的通知色冀，直到得到調(diào)用結(jié)果。
• 異步：當(dāng)一個(gè)異步調(diào)用發(fā)出去后柱嫌，調(diào)用者不能立即得到調(diào)用結(jié)果的返回锋恬。

對(duì)于異步調(diào)用，要想獲得結(jié)果编丘，一般有2種方式：

• 主動(dòng)輪詢異步調(diào)用的結(jié)果
• 被調(diào)用方通過(guò)callback來(lái)通知調(diào)用方調(diào)用結(jié)果

舉個(gè)栗子

• 同步買(mǎi)奶茶：小明點(diǎn)單交錢(qián)，然后等著拿奶茶。
• 異步買(mǎi)奶茶：小明點(diǎn)單交錢(qián)邓了，店員給小明一個(gè)小票，等小明奶茶做好了再來(lái)取晕窑。

異步買(mǎi)奶茶，小明要想知道奶茶是否做好了卵佛，有2種方式：

• 小明主動(dòng)去問(wèn)店員杨赤，一會(huì)就去問(wèn)一下：“奶茶做好了嗎？”...直到奶茶做好截汪。
• 等奶茶做好了疾牲，店員喊一聲：“小明，奶茶好了挫鸽！”说敏，然后小明去取奶茶。

總結(jié)：同步與異步的重點(diǎn)在消息通知的方式上丢郊，也就是調(diào)用結(jié)果通知的方式。

阻塞與非阻塞

• 阻塞調(diào)用發(fā)出去后医咨，在消息返回之前枫匾，當(dāng)前進(jìn)/線程會(huì)被掛起，直到有消息返回拟淮，當(dāng)前進(jìn)/線程才會(huì)被激活干茉。
• 非阻塞調(diào)用發(fā)出去后，不會(huì)阻塞當(dāng)前進(jìn)/線程很泊，而會(huì)立即返回角虫。

舉個(gè)栗子

• 阻塞買(mǎi)奶茶：小明點(diǎn)單交錢(qián)，干等著拿奶茶委造，什么事都不做戳鹅。
• 非阻塞買(mǎi)奶茶：小明點(diǎn)單交錢(qián)，等著拿奶茶昏兆，等的過(guò)程中枫虏，時(shí)不時(shí)刷刷微博、朋友圈...

同步與異步重點(diǎn)在于消息通知的方式爬虱，阻塞與非阻塞重點(diǎn)在于等消息時(shí)候的行為隶债。
所以，就有了下面4種組合方式：

• 同步阻塞：小明在柜臺(tái)干等著拿奶茶跑筝；
• 同步非阻塞：小明在柜臺(tái)邊刷微博邊等著拿奶茶死讹；
• 異步阻塞：小明拿著小票啥都不干，一直等著店員通知他拿奶茶曲梗；
• 異步非阻塞：小明拿著小票赞警，刷著微博逛腿，等著店員通知他拿奶茶。

總結(jié)：阻塞與非阻塞的重點(diǎn)在于進(jìn)/線程等待消息時(shí)候的行為仅颇，也就是在等待消息的時(shí)候单默，當(dāng)前進(jìn)/線程是掛起狀態(tài)，還是非掛起狀態(tài)忘瓦。

Nginx 如何處理高并發(fā)

Apache 面對(duì)高并發(fā)搁廓，為什么很無(wú)力耕皮？

Apache處理一個(gè)請(qǐng)求是同步阻塞的模式境蜕。如圖：

image

每到達(dá)一個(gè)請(qǐng)求，Apache都會(huì)去fork一個(gè)子進(jìn)程去處理這個(gè)請(qǐng)求凌停，直到這個(gè)請(qǐng)求處理完畢粱年。
面對(duì)低并發(fā)，這種模式?jīng)]什么缺點(diǎn)罚拟，但是台诗，面對(duì)高并發(fā)，就是這種模式的軟肋了赐俗。

1個(gè)客戶端占用1個(gè)進(jìn)程拉队，那么，進(jìn)程數(shù)量有多少阻逮，并發(fā)處理能力就有多少粱快，但操作系統(tǒng)可以創(chuàng)建的進(jìn)程數(shù)量是有限的。
并且叔扼，多進(jìn)程就會(huì)有進(jìn)程間的切換問(wèn)題事哭，而進(jìn)程間的切換調(diào)度勢(shì)必會(huì)造成CPU的額外消耗。當(dāng)進(jìn)程數(shù)量達(dá)到成千上萬(wàn)的時(shí)候瓜富，進(jìn)程間的切換就占了CPU大部分的時(shí)間片鳍咱，而真正進(jìn)程的執(zhí)行反而占了CPU的一小部分，這就得不償失了食呻。

下面流炕，舉例說(shuō)明這2種場(chǎng)景是多進(jìn)程模式的軟肋：

1、即時(shí)消息通知程序比如及時(shí)聊天程序仅胞，一臺(tái)服務(wù)器可能要維持?jǐn)?shù)十萬(wàn)的連接(典型的C10K問(wèn)題)每辟，那么就要啟動(dòng)數(shù)十萬(wàn)的進(jìn)程來(lái)維持。這顯然不可能干旧。

2渠欺、調(diào)用外部Http接口時(shí)假設(shè)Apache啟動(dòng)100個(gè)進(jìn)程來(lái)處理請(qǐng)求，每個(gè)請(qǐng)求消耗100ms椎眯，那么這100個(gè)進(jìn)程能提供1000qps挠将。
但是胳岂，在我們調(diào)用外部Http接口時(shí)，比如QQ登錄舔稀、微博登錄乳丰，耗時(shí)較長(zhǎng)，假設(shè)一個(gè)請(qǐng)求消耗10s内贮，也就是1個(gè)進(jìn)程1s處理0.1個(gè)請(qǐng)求产园，那么100個(gè)進(jìn)程只能達(dá)到10qps，這樣的處理能力就未免太差了夜郁。

注：什么是C10K問(wèn)題什燕？網(wǎng)絡(luò)服務(wù)在處理數(shù)以萬(wàn)計(jì)的客戶端連接時(shí)，往往出現(xiàn)效率低下甚至完全癱瘓竞端，這被稱為C10K問(wèn)題屎即。（concurrent 10000 connection）

綜上，我們可以看出事富，Apache是同步阻塞的多進(jìn)程模式技俐，面對(duì)高并發(fā)等一些場(chǎng)景，是很蒼白的赵颅。

Nginx 何以問(wèn)鼎高并發(fā)

傳統(tǒng)的服務(wù)器模型就是這樣虽另，因?yàn)槠?code>同步阻塞的多進(jìn)程模型，無(wú)法面對(duì)高并發(fā)饺谬。
那么，有沒(méi)有一種方式可以讓我們在一個(gè)進(jìn)程處理所有的并發(fā)I/O呢谣拣？
答案是有的募寨，這就是I/O復(fù)用技術(shù)。

I/O 復(fù)用是神馬森缠？

所謂的I/O復(fù)用拔鹰，就是多個(gè)I/O可以復(fù)用一個(gè)進(jìn)程。

上面說(shuō)的同步阻塞的多進(jìn)程模型不適合處理高并發(fā)贵涵，那么列肢，我們?cè)賮?lái)考慮非阻塞的方式。

采用非阻塞的模式宾茂，當(dāng)一個(gè)連接過(guò)來(lái)時(shí)瓷马，我們不阻塞住，這樣一個(gè)進(jìn)程可以同時(shí)處理多個(gè)連接了跨晴。

比如一個(gè)進(jìn)程接受了10000個(gè)連接欧聘，這個(gè)進(jìn)程每次從頭到尾的問(wèn)一遍這10000個(gè)連接：“有I/O事件沒(méi)？有的話就交給我處理端盆，沒(méi)有的話我一會(huì)再來(lái)問(wèn)一遍怀骤》逊猓”
然后進(jìn)程就一直從頭到尾問(wèn)這10000個(gè)連接，如果這1000個(gè)連接都沒(méi)有I/O事件蒋伦，就會(huì)造成CPU的空轉(zhuǎn)弓摘，并且效率也很低，不好不好痕届。

于是偉大的程序猿們?nèi)账家瓜氲娜ソ鉀Q這個(gè)問(wèn)題...終于韧献！

• 我們能不能引入一個(gè)代理，這個(gè)代理可以同時(shí)觀察許多I/O流事件呢爷抓？

當(dāng)沒(méi)有I/O事件的時(shí)候势决，這個(gè)進(jìn)程處于阻塞狀態(tài)；當(dāng)有I/O事件的時(shí)候蓝撇，這個(gè)代理就去通知進(jìn)程醒來(lái)果复？

于是，早期的程序猿們發(fā)明了兩個(gè)代理：select渤昌、poll虽抄。

• select、poll代理的原理是這樣的：

當(dāng)連接有I/O流事件產(chǎn)生的時(shí)候独柑，就會(huì)去喚醒進(jìn)程去處理迈窟。
但是進(jìn)程并不知道是哪個(gè)連接產(chǎn)生的I/O流事件，于是進(jìn)程就挨個(gè)去問(wèn)：“請(qǐng)問(wèn)是你有事要處理嗎忌栅？”......問(wèn)了99999遍车酣，哦，原來(lái)是第100000個(gè)進(jìn)程有事要處理索绪。那么湖员，前面這99999次就白問(wèn)了，白白浪費(fèi)寶貴的CPU時(shí)間片了瑞驱！痛哉娘摔，惜哉...

注：select與poll原理是一樣的，只不過(guò)select只能觀察1024個(gè)連接唤反，poll可以觀察無(wú)限個(gè)連接凳寺。

上面看了，select彤侍、poll因?yàn)椴恢滥膫€(gè)連接有I/O流事件要處理肠缨，性能也挺不好的。

那么拥刻，如果發(fā)明一個(gè)代理怜瞒，每次能夠知道哪個(gè)連接有了I/O流事件，不就可以避免無(wú)意義的空轉(zhuǎn)了嗎？

于是吴汪，超級(jí)無(wú)敵惠窄、閃閃發(fā)光的epoll被偉大的程序員發(fā)明出來(lái)了。

• epoll代理的原理是這樣的：

當(dāng)連接有I/O流事件產(chǎn)生的時(shí)候漾橙，epoll就會(huì)去告訴進(jìn)程哪個(gè)連接有I/O流事件產(chǎn)生杆融，然后進(jìn)程就去處理這個(gè)連接。

如此霜运，多高效脾歇！

基于 epoll 的 Nginx

有了epoll，理論上1個(gè)進(jìn)程就可以處理無(wú)限數(shù)量的連接淘捡，而且無(wú)需輪詢藕各，真正解決了c10k的問(wèn)題。

Nginx是基于epoll的焦除，異步非阻塞的服務(wù)器程序激况。自然，Nginx能夠輕松處理百萬(wàn)級(jí)的并發(fā)連接膘魄，也就無(wú)可厚非了乌逐。

Swoole 如何處理高并發(fā)以及異步 I/O 的實(shí)現(xiàn)

Swoole 介紹

• Swoole是PHP的一個(gè)擴(kuò)展。
• 簡(jiǎn)單理解：Swoole = 異步I/O + 網(wǎng)絡(luò)通信创葡。
• PHPer可以基于Swoole去實(shí)現(xiàn)過(guò)去PHP無(wú)法實(shí)現(xiàn)的功能浙踢。

具體請(qǐng)參考Swoole官網(wǎng)。

Swoole 如何處理高并發(fā)

• Reactor模型介紹

IO復(fù)用異步非阻塞程序使用經(jīng)典的Reactor模型灿渴，Reactor顧名思義就是反應(yīng)堆的意思洛波，它本身不處理任何數(shù)據(jù)收發(fā)。只是可以監(jiān)視一個(gè)socket（也可以是管道骚露、eventfd奋岁、信號(hào)）句柄的事件變化。

注：什么是句柄荸百？句柄英文為handler，可以形象的比喻為鍋柄滨攻、勺柄够话。也就是資源的唯一標(biāo)識(shí)符、資源的ID光绕。通過(guò)這個(gè)ID可以操作資源女嘲。

image

Reactor只是一個(gè)事件發(fā)生器，實(shí)際對(duì)socket句柄的操作诞帐，如connect/accept欣尼、send/recv、close是在callback中完成的。

Swoole 的架構(gòu)

• Swoole采用多線程Reactor+多進(jìn)程Worker愕鼓。

• Swoole的架構(gòu)圖如下：

image

• Swoole的處理連接流程圖如下：

image

• 當(dāng)請(qǐng)求到達(dá)時(shí)钙态，Swoole是這樣處理的：

image

因?yàn)?code>Reactor基于epoll，所以每個(gè)Reactor可以處理無(wú)數(shù)個(gè)連接請(qǐng)求菇晃。 如此册倒，Swoole就輕松的處理了高并發(fā)。

Swoole 如何實(shí)現(xiàn)異步I/O

基于上面的Swoole結(jié)構(gòu)圖磺送，我們看到Swoole的worker進(jìn)程有2種類型：
一種是普通的worker進(jìn)程驻子，一種是task worker進(jìn)程。

• worker進(jìn)程：用來(lái)處理普通的耗時(shí)不是太長(zhǎng)的請(qǐng)求
• task worker進(jìn)程：用來(lái)處理耗時(shí)較長(zhǎng)的請(qǐng)求估灿，比如數(shù)據(jù)庫(kù)的I/O操作

我們以異步MySQL舉例：

image

如此崇呵，通過(guò)worker、task worker結(jié)合的方式馅袁，我們就實(shí)現(xiàn)了異步I/O域慷。

via：微信公眾號(hào)文章