結論

先說答案，Nginx之所以支持高并發，是因為它是基于epoll的異步及非阻塞的事件驅動模型。 在這個模型下，Nginx服務端可以同一時間接收成千上萬個客戶端請求而不阻塞。這是因為Nginx會把一個一個的客戶端請求注冊成事件給到系統內核，而這個事件管理器完全由系統內核管理，Nginx只負責注冊和接收通知。下面再來詳細聊聊具體原因。

Nginx架構

Nginx啟動時，先啟動一個master進程，然后再根據配置文件里定義的參數來啟動對應數量的worker進程。

所以，Nginx是多進程模式，多個進程之間不會相互影響，多個worker進程還可以配置成使用不同的CPU來工作，從而提高了Nginx處理請求速度。

Nginx的異步非阻塞機制

首先理解同步和異步的概念，這兩個概念是從客戶端與服務端通信交互方式來說。

同步，指服務端接收到客戶端請求后，必須處理完該請求后（發送處理結果給客戶端），才會接收客戶端發送來的下一個請求。

異步，指服務端還沒有處理完客戶端請求（沒有發送處理結果給客戶端），就已經接收下一個客戶端發來的請求了。

再來理解阻塞和非阻塞的概念。這兩個概念是從服務器內部處理請求的方式來說的。

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

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

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

事件驅動模型

上面提到的異步非阻塞機制，Nginx是通過基于事件的驅動模型來實現的。這個模型下，客戶端發起的所有請求在服務端都會被標記為一個事件，Nginx會把這些事件收集到“事件收集器”里，然后再把這些事件交給內核去處理。

對于Nginx服務器來說，客戶端A的請求連接到服務端時，服務端進程（Nginx worker process）會處理該請求，此進程在沒有返回給客戶端A結果時，它又去處理了客戶端B的請求。 服務端把客戶端A以及客戶端B發來的請求作為事件交給了“事件收集器”，而“事件收集器”再把收集到的事件交由“事件發送器”發送給“事件處理器”進行處理。 最后“事件處理器”處理完該事件后，通知服務端進程，服務端進程再把結果返回給客戶端A、客戶端B。 在這個過程中，服務端進程做的事情屬于用戶級別的，而事件處理這部分工作屬于內核級別的。 也就是說這個事件驅動模型是需要操作系統內核來作為支撐的。

Nginx支持的事件驅動模型

Nginx支持的事件驅動模型有：select, poll, epoll, rtsig, kqueue, /dev/poll, eventport等，最常用的是前三種。

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

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

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