Nginx 多進程模型是如何實現高並發的？

Nginx 的Worker進程數一般設置與CPU核數相同，但疑惑的是就那麼幾個進程是如何實現高並發的？

謝邀。進程數與並發數不存在很直接的關係。這取決取server採用的工作方式。

如果一個server採用一個進程負責一個request的方式，那麼進程數就是並發數。那麼顯而易見的，就是會有很多進程在等待中。等什麼？最多的應該是等待網路傳輸。其缺點題主應該也感覺到了，此處不述。

而nginx 的非同步非阻塞工作方式正是利用了這點等待的時間。在需要等待的時候，這些進程就空閑出來待命了。因此表現為少數幾個進程就解決了大量的並發問題。

nginx是如何利用的呢，簡單來說：同樣的4個進程，如果採用一個進程負責一個request的方式，那麼，同時進來4個request之後，每個進程就負責其中一個，直至會話關閉。期間，如果有第5個request進來了。就無法及時反應了，因為4個進程都沒幹完活呢，因此，一般有個調度進程，每當新進來了一個request，就新開個進程來處理。

nginx不這樣，每進來一個request，會有一個worker進程去處理。但不是全程的處理，處理到什麼程度呢？處理到可能發生阻塞的地方，比如向上游（後端）伺服器轉發request，並等待請求返回。那麼，這個處理的worker不會這麼傻等著，他會在發送完請求後，註冊一個事件：「如果upstream返回了，告訴我一聲，我再接著干」。於是他就休息去了。此時，如果再有request 進來，他就可以很快再按這種方式處理。而一旦上游伺服器返回了，就會觸發這個事件，worker才會來接手，這個request才會接著往下走。

由於web server的工作性質決定了每個request的大部份生命都是在網路傳輸中，實際上花費在server機器上的時間片不多。這是幾個進程就解決高並發的秘密所在。即@skoo所說的

webserver剛好屬於網路io密集型應用，不算是計算密集型。

而@叔度所說的

非同步，非阻塞，使用epoll，和大量細節處的優化。

也正是nginx之所以然的技術基石。