聲明：本文的內容源於http://tengine.taobao.org/相關資料，如果想深入瞭解，可以到該網站查看。
nginx的高性能在業界已經是衆人皆知了，性能究竟有多高?官方測試Nginx能夠支撐5萬併發連接，在實際生產環境中可支撐2~4萬併發的連接數是沒有啥問題的。根據實戰Nginx書中描述，同等硬件環境下，Nginx的處理能力相當於Apache的5~10倍。而這麼高的性能，與其架構是分不開的。
nginx在啓動後，在unix系統中會以daemon的方式在後臺運行，後臺進程包含一個master進程和多個worker進程。master進程主要用來管理worker進程，包含：接收來自外界的信號、向各worker進程發送信號和監控worker進程的運行狀態等。當worker進程退出後(異常情況下)，會自動重新啓動新的worker進程。而基本的網絡事件，則是放在worker進程中來處理了。多個worker進程之間是對等的，他們同等競爭來自客戶端的請求，各進程互相之間是獨立的。一個請求，只可能在一個worker進程中處理，一個worker進程，不可能處理其它進程的請求。worker進程的個數是可以設置的，一般我們會設置與機器cpu核數一致，這裏面的原因與nginx的進程模型以及事件處理模型是分不開的。
nginx的進程模型，可以由下圖來表示：
從上圖中我們可以看到，master來管理worker進程，所以我們只需要與master進程通信就行了。master進程會接收來自外界發來的信號，再根據信號做不同的事情。所以我們要控制nginx，只需要通過kill向master進程發送信號就行了。
那麼，worker進行又是如何處理請求的呢？前面有提到，worker進程之間是平等的，每個進程，處理請求的機會也是一樣的。首先，每個worker進程都是從master進程fork過來，在master進程裏面，先建立好需要listen的socket（listenfd）之後，然後再fork出多個worker進程。所有worker進程的listenfd會在新連接到來時變得可讀，爲保證只有一個進程處理該連接，所有worker進程在註冊listenfd讀事件前搶accept_mutex，搶到互斥鎖的那個進程註冊listenfd讀事件，在讀事件裏調用accept接受該連接。當一個worker進程在accept這個連接之後，就開始讀取請求，解析請求，處理請求，產生數據後，再返回給客戶端，最後才斷開連接，這樣一個完整的請求就是這樣的了。我們可以看到，一個請求，完全由worker進程來處理，而且只在一個worker進程中處理。
nginx採用這種進程模型有什麼好處呢？當然，好處肯定會很多了。首先，對於每個worker進程來說，獨立的進程，不需要加鎖，所以省掉了鎖帶來的開銷，同時在編程以及問題查找時，也會方便很多。其次，採用獨立的進程，可以讓互相之間不會影響，一個進程退出後，其它進程還在工作，服務不會中斷，master進程則很快啓動新的worker進程。當然，worker進程的異常退出，肯定是程序有bug了，異常退出，會導致當前worker上的所有請求失敗，不過不會影響到所有請求，所以降低了風險。當然，好處還有很多，大家可以慢慢體會。
到這裏，有人可能要問了，nginx採用多worker的方式來處理請求，每個worker裏面只有一個主線程，那能夠處理的併發數很有限啊，多少個worker就能處理多少個併發，何來高併發呢？非也，這就是nginx的高明之處，nginx採用了異步非阻塞的方式來處理請求，也就是說，nginx是可以同時處理成千上萬個請求的。想想apache的常用工作方式（apache也有異步非阻塞版本，但因其與自帶某些模塊衝突，所以不常用），每個請求會獨佔一個工作線程，當併發數上到幾千時，就同時有幾千的線程在處理請求了。這對操作系統來說，是個不小的挑戰，線程帶來的內存佔用非常大，線程的上下文切換帶來的cpu開銷很大，自然性能就上不去了，而這些開銷完全是沒有意義的。
何爲異步非阻塞？我們先回到原點，看看一個請求的完整過程。首先，請求過來，要建立連接，然後再接收數據，接收數據後，再發送數據。具體到系統底層，就是讀寫事件，而當讀寫事件沒有準備好時，必然不可操作，如果不用非阻塞的方式來調用，那就得阻塞調用了，事件沒有準備好，那就只能等了，等事件準備好了，你再繼續吧。阻塞調用會進入內核等待，cpu就會讓出去給別人用了，對單線程的worker來說，顯然不合適，當網絡事件越多時，大家都在等待呢，cpu空閒下來沒人用，cpu利用率自然上不去了，更別談高併發了。好吧，你說加進程數，這跟apache的線程模型有什麼區別？注意，別增加無謂的上下文切換。所以，在nginx裏面，最忌諱阻塞的系統調用了。不要阻塞，那就非阻塞嘍。非阻塞就是，事件沒有準備好，馬上返回EAGAIN，告訴你，事件還沒準備好呢，你慌什麼，過會再來吧。好吧，你過一會，再來檢查一下事件，直到事件準備好了爲止，在這期間，你就可以先去做其它事情，然後再來看看事件好了沒。雖然不阻塞了，但你得不時地過來檢查一下事件的狀態，你可以做更多的事情了，但帶來的開銷也是不小的。所以，纔會有了異步非阻塞的事件處理機制，具體到系統調用就是像select/poll/epoll/kqueue這樣的系統調用。它們提供了一種機制，讓你可以同時監控多個事件，調用他們是阻塞的，但可以設置超時時間，在超時時間之內，如果有事件準備好了，就返回。這種機制正好解決了我們上面的兩個問題，拿epoll爲例(在後面的例子中，我們多以epoll爲例子，以代表這一類函數)，當事件沒準備好時，放到epoll裏面，事件準備好了，我們就去讀寫，當讀寫返回EAGAIN時，我們將它再次加入到epoll裏面。這樣，只要有事件準備好了，我們就去處理它，只有當所有事件都沒準備好時，纔在epoll裏面等着。這樣，我們就可以併發處理大量的併發了，當然，這裏的併發請求，是指未處理完的請求，線程只有一個，所以同時能處理的請求當然只有一個了，只是在請求間進行不斷地切換而已，切換也是因爲異步事件未準備好，而主動讓出的。這裏的切換是沒有任何代價，你可以理解爲循環處理多個準備好的事件，事實上就是這樣的。與多線程相比，這種事件處理方式是有很大的優勢的，不需要創建線程，每個請求佔用的內存也很少，沒有上下文切換，事件處理非常的輕量級。併發數再多也不會導致無謂的資源浪費（上下文切換）。更多的併發數，只是會佔用更多的內存而已。
現在的網絡服務器基本都採用這種方式，這也是nginx性能高效的主要原因。