閱前熱身

超過十年行業(yè)經(jīng)驗，技術領先，服務至上的經(jīng)營模式，全靠網(wǎng)絡和口碑獲得客戶，為自己降低成本，也就是為客戶降低成本。到目前業(yè)務范圍包括了：成都網(wǎng)站建設、網(wǎng)站建設，成都網(wǎng)站推廣，成都網(wǎng)站優(yōu)化，整體網(wǎng)絡托管，小程序設計，微信開發(fā)，成都app軟件開發(fā)，同時也可以讓客戶的網(wǎng)站和網(wǎng)絡營銷和我們一樣獲得訂單和生意！

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

同步與異步

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

同步：當一個同步調(diào)用發(fā)出去后，調(diào)用者要一直等待調(diào)用結(jié)果的通知，直到得到調(diào)用結(jié)果。

異步：當一個異步調(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、等奶茶做好了，店員喊一聲：“小吳，奶茶好了！”，然后小吳去取奶茶。

阻塞與非阻塞

阻塞與非阻塞的重點在于進/線程等待消息時候的行為，也就是在等待消息的時候，當前進/線程是掛起狀態(tài)，還是非掛起狀態(tài)。

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

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

舉個栗子：

1、阻塞買奶茶：小吳點單交錢，干等著拿奶茶，什么事都不做；

2、非阻塞買奶茶：小吳點單交錢，等著拿奶茶，等的過程中，時不時刷刷微博、朋友圈...

Submit

同步與異步，重點在于消息通知的方式;

阻塞與非阻塞，重點在于等消息時候的行為。

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

同步阻塞：小吳在柜臺干等著拿奶茶；

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

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

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

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

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種場景是多進程模式的軟肋：

1、及時消息通知程序比如及時聊天程序，一臺服務器可能要維持數(shù)十萬的連接(典型的C10K問題)，那么就要啟動數(shù)十萬的進程來維持。這顯然不可能。

2、調(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ā)等一些場景，是很蒼白的。

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

傳統(tǒng)的服務器模型就是這樣，因為其同步阻塞的多進程模型，無法面對高并發(fā)。

那么，有沒有一種方式，可以讓我們在一個進程處理所有的并發(fā)I/O呢？

答案是有的，這就是I/O復用技術。

①、I/O復用是神馬？

所謂的I/O復用，就是多個I/O可以復用一個進程。

上面說的同步阻塞的多進程模型不適合處理高并發(fā)，那么，我們再來考慮非阻塞的方式。

采用非阻塞的模式，當一個連接過來時，我們不阻塞住，這樣一個進程可以同時處理多個連接了。

比如一個進程接受了10000個連接，這個進程每次從頭到尾的問一遍這10000個連接：“有I/O事件沒？有的話就交給我處理，沒有的話我一會再來問一遍?！?/p>

然后進程就一直從頭到尾問這10000個連接，如果這1000個連接都沒有I/O事件，就會造成CPU的空轉(zhuǎn)，并且效率也很低，不好不好。

于是偉大的程序猿們?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ā)連接，也就無可厚非了。

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

swoole介紹

swoole是PHP的一個擴展。

簡單理解：swoole=異步I/O+網(wǎng)絡通信

PHPer可以基于swoole去實現(xiàn)過去PHP無法實現(xiàn)的功能。

具體請參考swoole官網(wǎng)。

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是這樣處理的：

因為reactor基于epoll，所以每個reactor可以處理無數(shù)個連接請求。 如此，swoole就輕松的處理了高并發(fā)。

swoole如何實現(xiàn)異步I/O

基于上面的Swoole結(jié)構(gòu)圖，我們看到swoole的worker進程有2種類型：

一種是 普通的worker進程，一種是 task worker進程。

worker進程是用來處理普通的耗時不是太長的請求；task worker進程用來處理耗時較長的請求，比如數(shù)據(jù)庫的I/O操作。

我們以異步Mysql舉例：

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

讀者福利

加微信：haolagui521備注51CTO領取附送學習進階架構(gòu)資料、PDF書籍文檔、面試資料

創(chuàng)新互聯(lián)www.cdcxhl.cn，專業(yè)提供香港、美國云服務器，動態(tài)BGP最優(yōu)骨干路由自動選擇，持續(xù)穩(wěn)定高效的網(wǎng)絡助力業(yè)務部署。公司持有工信部辦法的idc、isp許可證， 機房獨有T級流量清洗系統(tǒng)配攻擊溯源，準確進行流量調(diào)度，確保服務器高可用性。佳節(jié)活動現(xiàn)已開啟，新人活動云服務器買多久送多久。

分享文章：nginx、swoole高并發(fā)原理初探-創(chuàng)新互聯(lián)
分享鏈接：http://chinadenli.net/article18/djjcdp.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供ChatGPT、微信小程序、外貿(mào)網(wǎng)站建設、移動網(wǎng)站建設、云服務器、定制開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)