先總結：nginx是異步非阻塞工作方式，平時設置nginx的worker進程數時，設置的和CPU核數相同比較合適。
我們平時在設置Nginx 的Worker進程數時，一般設置與CPU核數相同，這是爲什麼？爲什麼幾個進程就可以實現高併發呢？
因爲進程數與併發數不存在很直接的關係，主要還是取決server採用的工作方式，如果一個server採用一個進程負責一個request請求的方式，那麼進程數就是併發數。這樣就是會有很多進程在等待網絡傳輸，缺點題主大家應該都知道。
nginx 的異步非阻塞工作方式正是利用了這點等待的時間，在需要等待的時候，這些進程就空閒出來待命了。因此表現爲少數幾個進程就解決了大量的併發問題。
nginx是如何利用的呢，簡單來說：同樣的4個進程，如果採用一個進程負責一個request的方式，那麼，同時進來4個request之後，每個進程就負責其中一個，直至會話關閉。期間，如果有第5個request進來了。就無法及時反應了，因爲4個進程都沒幹完活呢，因此，一般有個調度進程，每當新進來了一個request，就新開個進程來處理。
nginx不是這樣的，nginx每進來一個request，會有一個worker進程去處理。但不是全程的處理，處理到什麼程度呢？處理到可能發生阻塞的地方，比如向上遊（後端）服務器轉發request，並等待請求返回。那麼，這個處理的worker不會這麼傻等着，他會在發送完請求後，註冊一個事件：“如果upstream返回了，告訴我一聲，我再接着幹”。於是他就休息去了。此時，如果再有request 進來，他就可以很快再按這種方式處理。而一旦上游服務器返回了，就會觸發這個事件，worker纔會來接手，這個request纔會接着往下走。
由於web server的工作性質決定了每個request的大部份生命都是在網絡傳輸中，實際上花費在server機器上的時間片不多，這就是爲什麼幾個進程就解決了高併發。