簡單來講，就是異步，非阻塞，使用了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使用教程欄目進行學習！
