Nginx高并發(fā)原理簡析

IT那活兒發(fā)布于2023-01-11 13:20 / 2905人閱讀

Nginx高并發(fā)原理簡析

【背景概述】

Nginx是一款輕量級的Web服務(wù)器/反向代理服務(wù)器及電子郵件（IMAP/POP3）代理服務(wù)器，其特點是占有內(nèi)存少、并發(fā)能力強，因它的穩(wěn)定性、豐富的功能集、示例配置文件和低系統(tǒng)資源的消耗而聞名，也由此受到了很多大廠的青睞。

那么Nginx是如何實現(xiàn)的高并發(fā)的呢？下面將為大家分享一下Nginx架構(gòu)設(shè)計，探究一下Nginx備受青睞的秘訣在哪里。

Nginx的進程結(jié)構(gòu)

Nginx其實有兩種進程結(jié)構(gòu)，一種是單進程結(jié)構(gòu)，一種是多進程結(jié)構(gòu)。在我們實際生產(chǎn)環(huán)境中，由于需要保持nginx的健壯性，因此多進程結(jié)構(gòu)較為實用且常見。

為什么是多進程結(jié)構(gòu)，而不是多線程結(jié)構(gòu)？

首先我們來看一下多進程與多線程的對比：

Nginx最核心的一個目的是要保持高可用性、高可靠性，在采用多進程結(jié)構(gòu)時，由于和進程間不會相互影響，單個進程出現(xiàn)異常并不會導(dǎo)致整個Nginx服務(wù)掛掉。同時，多個worker進程可以分別占用不同的CPU核心來工作，提高了Nginx處理請求的速度。另外，采用多進程模型還可以通過進程間通信來實現(xiàn)負載均衡，即一個請求到來時更容易被分配到負載較輕的worker工作進程中處理，這也同樣提高了Nginx的請求處理能力。

如上圖所示，Nginx在啟動后，會有一個master進程和多個worker進程。

master進程主要用來做worker進程的管理，包含：接收來自外界的信號、向各worker進程發(fā)送信號、監(jiān)控worker進程的運行狀態(tài)、Nginx配置文件重新載入等。worker進程，才是處理真正請求的工作進程。

cache（緩存）是在多個worker進程間共享的，而且緩存不僅要被worker進程使用，還要被cachemanager 和cacheloader進程使用。cachemanager 和cacheloader 也是為反向代理時，后端發(fā)來的動態(tài)請求做緩存所使用的，cacheloader 只是用來做緩存的載入、cachemanager 用來做緩存的管理。實際上每個請求處理時，使用到緩存還是由worker進程來進行的。

這些進程間的通訊，都是使用共享內(nèi)存來解決的?？梢钥吹絚achemanager 和cacheloader各有一個進程，master進程因為是父進程，所以肯定只有一個。那么worker進程為什么會有很多呢？這是因為Nginx采用了事件驅(qū)動引擎以后，他希望每一個worker進程從頭到尾占有一顆CPU，所以往往不止要把worker進程的數(shù)量配置與我們服務(wù)器上的CPU核數(shù)一致以外，還需要把每一個worker進程與某一顆CPU核綁定在一起，這樣可以更好的使用每顆CPU核上面的CPU緩存來減少緩存失效的命中率。

Nginx的異步非阻塞處理機制

基本概念:

異步、同步

同步和異步，這兩個概念是從客戶端與服務(wù)器之間的通信交互方式得來的。

同步，指客戶端向服務(wù)器發(fā)送一個請求后、必須接收到服務(wù)器對此請求的響應(yīng)后，才會再向服務(wù)器發(fā)送下一個請求。

異步，指客戶端向服務(wù)器發(fā)送一個請求后，并不等待服務(wù)器對此請求的響應(yīng)，便發(fā)送了下一個請求。

阻塞、非阻塞

阻塞和非阻塞，這兩個概念是從服務(wù)器內(nèi)部處理請求的方式來說的。

阻塞，指服務(wù)器接收到請求后，如果遇到IO阻塞，當前線程會被掛起，知道IO完成后喚醒當前線程，當前線程期間不會去處理其他事情。

非阻塞，指服務(wù)器接收到請求后，如果遇到IO阻塞，當前線程不會掛起，而是會立即返回去執(zhí)行下一個調(diào)用。

同步與異步，重點在于消息通知的方式；阻塞與非阻塞，重點在于等消息時候的行為。

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

同步阻塞：小明收到信息后，啥都不干，等快遞；

同步非阻塞：小明收到信息后，邊刷微博，邊等著取快遞；

異步阻塞：小明收到信息后，啥都不干，一直等著快遞員通知他取快遞；

異步非阻塞：小明收到信息后，邊刷著微博，邊等快遞員通知他取快遞。

Nginx之所以可以支持高并發(fā)，就是因為Nginx用的是上述所講的異步非阻塞的機制，而Nginx是靠事件驅(qū)動模型來實現(xiàn)這種機制的。

在Nginx的事件驅(qū)動模型下，客戶端發(fā)起的所有請求在服務(wù)端都會被標記為一個事件，Nginx會把這些事件收集到“事件收集器”里，然后再把這些事件交給內(nèi)核去處理。

Nginx的事件驅(qū)動模型

Nginx的事件驅(qū)動模型，支持select、poll、epoll、rtsig、kqueue、/dev/poll、eventport等，最常用的是前三種。

Select模型：首先會創(chuàng)建所關(guān)注事件的描述符集合。會分別創(chuàng)建讀（Read）事件、寫（Write）事件、異常發(fā)生（Exception）事件三類描述符集合來收集三類描述符。然后調(diào)用底層提供的select()函數(shù)，等待事件發(fā)生。最后輪詢所有事件描述符集合中的每一個描述符，檢查是否有相應(yīng)的事件發(fā)生，然后處理事件。

Poll模型：其與select的基本實現(xiàn)方式相同，只不過創(chuàng)建關(guān)注的描述符集合時，不分成三個集合，而是一個集合包括所有描述符。

Epoll模型：當描述符比較多時，遍歷描述符集合、然后查找每個描述符是否有相應(yīng)事件發(fā)生這一過程會效率較低。epoll選擇將描述符列表的管理交給內(nèi)核復(fù)制，一旦有事件發(fā)生，內(nèi)核會將有事件發(fā)生的描述符列表通知給進程，這樣避免了應(yīng)用程序輪詢整個描述符列表。epoll會通過相關(guān)調(diào)用，通知內(nèi)核創(chuàng)建一個N個描述符的事件列表，然后給這些描述符設(shè)置所關(guān)注的事件，并把他添加到內(nèi)核的事件列表中，在編碼過程中也可以通過相關(guān)調(diào)用對事件列表中的描述符進行動態(tài)地刪除和修改。

總結(jié)

Nginx是如何實現(xiàn)高并發(fā)的？

如果一個server采用一個進程負責一個request的方式，那么進程數(shù)就是并發(fā)數(shù)。正常情況下，會有很多進程一直在等待中。而nginx采用一個master進程，多個woker進程的模式。master進程主要負責收集、分發(fā)請求。每當一個請求過來時，master就拉起一個worker進程負責處理這個請求。同時master進程也負責監(jiān)控woker的狀態(tài)，保證高可靠性。woker進程一般設(shè)置為跟cpu核心數(shù)一致。nginx的woker進程在同一時間可以處理的請求數(shù)只受內(nèi)存限制，可以處理多個請求。Nginx的異步非阻塞工作方式正把當中的等待時間利用起來了。在需要等待的時候，這些進程就空閑出來待命了，因此表現(xiàn)為少數(shù)幾個進程就解決了大量的并發(fā)問題。每進來一個request，會有一個worker進程去處理。但不是全程的處理，處理到什么程度呢?處理到可能發(fā)生阻塞的地方，比如向上游(后端)服務(wù)器轉(zhuǎn)發(fā)request，并等待請求返回。那么，這個處理的worker很聰明，他會在發(fā)送完請求后，注冊一個事件：“如果upstream返回了，告訴我一聲，我再接著干”。于是他就休息去了。此時，如果再有request進來，他就可以很快再按這種方式處理。而一旦上游服務(wù)器返回了，就會觸發(fā)這個事件，worker才會來接手，這個request才會接著往下走。

因此，多進程結(jié)構(gòu)、異步非阻塞的處理機制和采用事件驅(qū)動模型（epoll）就是Nginx實現(xiàn)高并發(fā)的秘密所在。