簡單來講，就是非同步，非阻塞，使用了epoll和大量的底層程式碼最佳化。
稍微詳細一點展開的話，就是nginx的特殊行程模型和事件模型的設計。
影片課程推薦→：《千萬級資料並發解決方案（理論實戰）》
進程模型
nginx採用一個master進程，多個woker進程的模式。
master流程主要負責收集、分發請求。當一個請求過來時，master拉起一個worker進程負責處理這個請求。
master進程也要負責監控woker的狀態，保證高可靠性
woker進程一般設定為跟cpu核心數一致。 nginx的woker進程跟apache不一樣。 apche的進程在同一時間只能處理一個請求，所以它會開很多進程，幾百甚至幾千個。而nginx的woker進程在同一時間可以處理額請求數只受記憶體限制，因此可以處理多個請求。
事件模型
nginx是非同步非阻塞的。
每進來一個request，就會有一個worker行程去處理。但不是全程的處理，處理到什麼程度呢？處理到可能發生阻塞的地方，例如向上游（後端）伺服器轉送request，並等待請求返回。那麼，這個處理的worker不會這麼傻等著，他會在發送完請求後，註冊一個事件：「如果upstream返回了，告訴我一聲，我再接著幹」。於是他就休息去了。此時，如果再有request 進來，他就可以很快再用這種方式處理。而一旦上游伺服器回傳了，就會觸發這個事件，worker才會來接手，這個request才會接著往下走。
web server的工作性質決定了每個request的大部份生命都是在網路傳輸中，實際上花費在server機器上的時間片不多。這是幾個進程就解決高並發的秘密所在。
IO多路復用模型epoll
epoll() ，核心維護一個鍊錶，epoll_wait 直接檢查鍊錶是不是空就知道是否有檔案描述子準備好了。核心實作epoll 是根據每個 sockfd 上面的與裝置驅動程式建立的 回呼函數 實現的。那麼，某個 sockfd 上的事件發生時，與它對應的回呼函數就會被調用，來把這個 sockfd 加入鍊錶，其他處於「空閒的」狀態的則不會。
select() ，核心採用 輪訓 的方法來查看是否有fd 準備好，其中的保存 sockfd 的是類似數組的資料結構 fd_set，key 為 fd，value 為 0 或 1。
poll()
【總結】：epoll 與 select 相比最大的優點是不會隨著 sockfd 數目成長而降低效率。
更多Nginx相關技術文章，請造訪Nginx使用教學欄位進行學習！
以上是nginx如何實現高並發的詳細內容。更多資訊請關注PHP中文網其他相關文章！
