nginx、swoole高併發原理初探

原文：https://segmentfault.com/a/1190000007614502

1、閱前熱身

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

一、同步與異步

①同步與異步的理解

同步與異步的重點在消息通知的方式上，也就是調用結果通知的方式。

• 同步當一個同步調用發出去後，調用者要一直等待調用結果的通知後，才能進行後續的執行

• 異步：當一個異步調用發出去後，調用者不能當即獲得調用結果的返回。

異步調用，要想得到結果，通常有兩種方式：
一、主動輪詢異步調用的結果;
二、被調用方經過callback來通知調用方調用結果。

②：生活實例

同步買奶茶：小明點單交錢，而後等着拿奶茶；異步買奶茶：小明點單交錢，店員給小明一個小票，等小明奶茶作好了，再來取。

異步買奶茶，小明要想知道奶茶是否作好了，有兩種方式：
一、小明主動去問店員，一會就去問一下：「奶茶作好了嗎？」...直到奶茶作好。
二、等奶茶作好了，店員喊一聲：「小明，奶茶好了！」，而後小明去取奶茶。

---

二、阻塞與非阻塞

①阻塞與非阻塞的理解

阻塞與非阻塞的重點在於進/線程等待消息時候的行爲，也就是在等待消息的時候，當前進/線程是掛起狀態，仍是非掛起狀態。

• 阻塞阻塞調用在發出去後，在消息返回以前，當前進/線程會被掛起，直到有消息返回，當前進/線程纔會被激活.

• 非阻塞非阻塞調用在發出去後，不會阻塞當前進/線程，而會當即返回。

②：生活實例

阻塞買奶茶：小明點單交錢，乾等着拿奶茶，什麼事都不作；非阻塞買奶茶：小明點單交錢，等着拿奶茶，等的過程當中，時不時刷刷微博、朋友圈...

---

三、總結

經過上面的分析，咱們能夠得知：

同步與異步，重點在於消息通知的方式;阻塞與非阻塞，重點在於等消息時候的行爲。

因此，就有了下面4種組合方式

• 同步阻塞：小明在櫃檯乾等着拿奶茶；

• 同步非阻塞：小明在櫃檯邊刷微博邊等着拿奶茶；

• 異步阻塞：小明拿着小票啥都不幹，一直等着店員通知他拿奶茶；

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

---

2、Nginx如何處理高併發

一、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是同步阻塞的多進程模式，面對高併發等一些場景，是很蒼白的。

---

二、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可以輕鬆處理百萬級的併發鏈接，也就無可厚非了。

3、swoole如何處理高併發以及異步I/O的實現

一、swoole介紹

swoole是PHP的一個擴展。
簡單理解：swoole=異步I/O+網絡通訊
PHPer能夠基於swoole去實現過去PHP沒法實現的功能。
具體請參考swoole官網：swoole官網

---

二、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就輕鬆的處理了高併發。

三、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。