nginx、swoole高并發(fā)原理初探

閱前熱身

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

同步與異步

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

同步：當(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é)果的返回。

異步調(diào)用，要想獲得結(jié)果，一般有兩種方式：

1、主動(dòng)輪詢(xún)異步調(diào)用的結(jié)果;

2、被調(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)奶茶，小吳要想知道奶茶是否做好了，有兩種方式：

1、小吳主動(dòng)去問(wèn)店員，一會(huì)就去問(wèn)一下：“奶茶做好了嗎？”...直到奶茶做好。

2、等奶茶做好了，店員喊一聲：“小吳，奶茶好了！”，然后小吳去取奶茶。

阻塞與非阻塞

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

1、阻塞調(diào)用發(fā)出去后，在消息返回之前，當(dāng)前進(jìn)/線(xiàn)程會(huì)被掛起，直到有消息返回，當(dāng)前進(jìn)/線(xiàn)程才會(huì)被激活。

2、非阻塞調(diào)用發(fā)出去后，不會(huì)阻塞當(dāng)前進(jìn)/線(xiàn)程，而會(huì)立即返回。

舉個(gè)栗子：

1、阻塞買(mǎi)奶茶：小吳點(diǎn)單交錢(qián)，干等著拿奶茶，什么事都不做；

2、非阻塞買(mǎi)奶茶：小吳點(diǎn)單交錢(qián)，等著拿奶茶，等的過(guò)程中，時(shí)不時(shí)刷刷微博、朋友圈...

Submit

同步與異步，重點(diǎn)在于消息通知的方式;

阻塞與非阻塞，重點(diǎn)在于等消息時(shí)候的行為。

所以，就有了下面4種組合方式

同步阻塞：小吳在柜臺(tái)干等著拿奶茶；

同步非阻塞：小吳在柜臺(tái)邊刷微博邊等著拿奶茶；

異步阻塞：小吳拿著小票啥都不干，一直等著店員通知他拿奶茶；

異步非阻塞：小吳拿著小票，刷著微博，等著店員通知他拿奶茶。

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

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

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

每到達(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è)客戶(hù)端占用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ì)的客戶(hù)端連接時(shí)，往往出現(xiàn)效率低下甚至完全癱瘓，這被稱(chēng)為C10K問(wèn)題。（concurrent 10000 connection）

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

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

傳統(tǒng)的服務(wù)器模型就是這樣，因?yàn)槠渫阶枞亩噙M(jìn)程模型，無(wú)法面對(duì)高并發(fā)。

那么，有沒(méi)有一種方式，可以讓我們?cè)谝粋€(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)？有的話(huà)就交給我處理，沒(méi)有的話(huà)我一會(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è)進(jìn)程。

如此，多高效！

②、基于epoll的Nginx

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

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

3swoole如何處理高并發(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可以操作資源。

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

swoole的架構(gòu)

swoole采用?多線(xiàn)程Reactor+多進(jìn)程Worker

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

swoole的處理連接流程圖如下：

當(dāng)請(qǐng)求到達(dá)時(shí),swoole是這樣處理的：

因?yàn)閞eactor基于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種類(lèi)型：

一種是 普通的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舉例：

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

讀者福利

加微信：haolagui521備注51CTO領(lǐng)取附送學(xué)習(xí)進(jìn)階架構(gòu)資料、PDF書(shū)籍文檔、面試資料