Nginx是大型架構的必備中間件，下面我就全面來詳解Nginx抗住百萬并發背后的技術。

Nginx核心架構

Nginx 采用經典的 Master-Worker 進程模型，這種設計是其高性能、和高可用性的基石。

整體架構，如下圖所示：

+-------------+
|Master|
+------+------+
|
+------------+------------+
||
+----+----++-----+-----+
|Worker1||Worker2|
+----+----++-----+-----+

Master 進程，主要負責讀取、和解析配置文件，以及，管理 Worker 進程的啟動、關閉和重啟…等等。

Worker 進程，處理客戶端的請求，比如： HTTP 請求、TCP/UDP …連接等等等。

通常，Worker 進程的數量會配置為與服務器的 CPU 核心數相同、或兩倍，以便充分利用多核 CPU 的并行處理能力。

多個 Worker 進程可以并行處理請求，充分發揮多核 CPU 的性能。

高性能事件驅動模型

高性能事件驅動模型，這是 Nginx 能夠處理百萬并發的核心。

與傳統的“一個連接一個線程/進程”模型不同，Nginx 采用事件驅動模型。

如下圖所示：

1. epoll_wait 等待就緒事件（如連接/讀/寫）
2.就緒事件觸發，執行對應回調 handler（如讀取數據）
3.繼續監聽下一批事件

事件驅動模型的核心是：程序不再被動地等待任務、或按照固定的流程執行。

而是主動地監聽，并響應各種“事件”的發生。

比如：當一個事件發生時（如網絡數據到達、定時器觸發、用戶操作…等），程序會執行預先注冊好的回調函數來處理它。

Nginx 并不“主動干活”，而是“事件來了才響應”，這大幅減少了空耗、與阻塞。

IO多路復用

事件驅動模型的底層支撐，就是操作系統提供的 I/O 多路復用機制。

Nginx 在 Linux 下默認使用 epoll，性能極高。

epoll 采用了一種“事件就緒通知”機制，當某個文件描述符上的事件就緒時（例如，數據可讀）。

內核會主動，將其添加到 epoll 實例維護的一個就緒列表（ready list）中。

epoll 相比 select/poll，不僅能支持百萬連接，而且是“事件通知機制”，避免無效遍歷。

所以，I/O 多路復用的價值，可以大幅提升并發能力。

異步非阻塞 I/O

Nginx 的所有 I/O 操作都是 異步非阻塞的，這意味著：不需要線程等待數據，所有 read/write 都立刻返回。

這樣，可以確保 Nginx 的 Worker 進程，永遠不會在 I/O 操作上被掛起，它總是忙于處理那些已經就緒的事件。

客戶端連接 socket →注冊讀事件（非阻塞）→等數據到達
→數據到達觸發事件→回調讀取→注冊寫事件
→數據寫回→關閉或保持連接（Keepalive）

總之，異步非阻塞 I/O ，是與事件驅動模型、I/O 多路復用緊密結合，這是Nginx實現高性能的核心。

閱讀原文：原文鏈接