首先我們要知道，nginx 采用的是多進程（單線程） & 多路IO復用模型。使用了 I/O 多路復用技術的 Nginx，就成了”并發事件驅動“的服務器。
（推薦教程：nginx教程）
多進程的工作模式
Nginx 在啟動后，會有一個 master 進程和多個相互獨立的 worker 進程。master 接收來自外界的信號，向各 worker 進程發送信號，每個進程都有可能來處理這個連接。master 進程能監控 worker 進程的運行狀態，當 worker 進程退出后(異常情況下)，會自動啟動新的 worker 進程。
注意 worker 進程數，一般會設置成機器 cpu 核數。因為更多的 worker 數，只會導致進程相互競爭 cpu ，從而帶來不必要的上下文切換。
使用多進程模式，不僅能提高并發率，而且進程之間相互獨立，一個 worker 進程掛了不會影響到其他 worker 進程。
驚群現象
主進程（master 進程）首先通過 socket() 來創建一個 sock 文件描述符用來監聽，然后fork生成子進程（workers 進程），子進程將繼承父進程的 sockfd（socket 文件描述符），之后子進程 accept() 后將創建已連接描述符（connected descriptor），然后通過已連接描述符來與客戶端通信。
那么，由于所有子進程都繼承了父進程的 sockfd，那么當連接進來時，所有子進程都將收到通知并“爭著”與它建立連接，這就叫“驚群現象”。大量的進程被激活又掛起，只有一個進程可以accept() 到這個連接，這當然會消耗系統資源。
Nginx對驚群現象的處理
Nginx 提供了一個 accept_mutex 這個東西，這是一個加在accept上的一把共享鎖。即每個 worker 進程在執行 accept 之前都需要先獲取鎖，獲取不到就放棄執行 accept()。有了這把鎖之后，同一時刻，就只會有一個進程去 accpet()，這樣就不會有驚群問題了。 accept_mutex 是一個可控選項，我們可以顯示地關掉，默認是打開的。
Nginx進程詳解
Nginx在啟動后，會有一個master進程和多個worker進程。
master進程
主要用來管理worker進程，包含：
接收來自外界的信號向各worker進程發送信號監控worker進程的運行狀態，當worker進程退出后(異常情況下)，會自動重新啟動新的worker進程
master進程充當整個進程組與用戶的交互接口，同時對進程進行監護。它不需要處理網絡事件，不負責業務的執行，只會通過管理worker進程來實現重啟服務、平滑升級、更換日志文件、配置文件實時生效等功能。
我們要控制nginx，只需要通過 kill 向master進程發送信號就行了。比如kill -HUP pid 是告訴nginx從容地重啟nginx。我們一般用這個信號來重啟nginx，或重新加載配置，因為是從容地重啟，因此服務是不中斷的。master進程在接收到HUP信號后是怎么做的呢？
首先master進程在接到信號后，會先重新加載配置文件然后再啟動新的worker進程并向所有老的worker進程發送信號，告訴他們可以光榮退休了新的worker在啟動后，就開始接收新的請求，
老的worker在收到來自master的信號后，就不再接收新的請求，并且在當前進程中的所有未處理完的請求處理完成后，再退出。
當然，直接給master進程發送信號，這是比較老的操作方式，nginx在0.8版本之后，引入了一系列命令行參數，來方便我們管理。比如 ./nginx -s reload 就是來重啟nginx，./nginx -s stop 就是來停止nginx的運行。如何做到的呢？我們還是拿reload 來說，我們看到，執行命令時，我們是啟動一個新的nginx進程，而新的nginx進程在解析到reload參數后，就知道我們的目的是控制nginx來重新加載配置文件了，它會向master進程發送信號，然后接下來的動作，就和我們直接向master進程發送信號一樣了。
worker進程
而基本的網絡事件，則是放在worker進程中來處理了。多個worker進程之間是對等的，他們同等競爭來自客戶端的請求，各進程互相之間是獨立的。一個請求只可能在一個worker進程中處理，一個worker進程不可能處理其它進程的請求。worker進程的個數是可以設置的，一般我們會設置與機器cpu核數一致，這里面的原因與nginx的進程模型以及事件處理模型是分不開的。
worker進程之間是平等的，每個進程處理請求的機會也是一樣的。當我們提供80端口的http服務時，一個連接請求過來，每個進程都有可能處理這個連接，怎么做到的呢？首先，每個worker進程都是從master進程fork過來，在master進程里面，先建立好需要listen的socket（listenfd）之后，然后再fork出多個worker進程。所有worker進程的listenfd會在新連接到來時變得可讀，為保證只有一個進程處理該連接，所有worker進程在注冊listenfd讀事件前搶accept_mutex，搶到互斥鎖的那個進程注冊listenfd讀事件，在讀事件里調用accept接受該連接。當一個worker進程在accept這個連接之后，就開始讀取請求，解析請求，處理請求，產生數據后，再返回給客戶端，最后才斷開連接，這樣一個完整的請求就是這樣的了。我們可以看到，一個請求，完全由worker進程來處理，而且只在一個worker進程中處理。
worker進程工作流程
當一個 worker 進程在 accept() 這個連接之后，就開始讀取請求，解析請求，處理請求，產生數據后，再返回給客戶端，最后才斷開連接，一個完整的請求。一個請求完全由 worker 進程來處理，而且只能在一個 worker 進程中處理。
這樣做帶來的好處：
節省鎖帶來的開銷。每個 worker 進程都是獨立的進程，不共享資源，不需要加鎖。同時在編程以及問題查上時，也會方便很多。獨立進程，減少風險。采用獨立的進程，可以讓互相之間不會影響，一個進程退出后，其它進程還在工作，服務不會中斷，master 進程則很快重新啟動新的 worker 進程。當然，worker 進程的也能發生意外退出。
多進程模型每個進程/線程只能處理一路IO，那么 Nginx是如何處理多路IO呢？
如果不使用 IO 多路復用，那么在一個進程中，同時只能處理一個請求，比如執行 accept()，如果沒有連接過來，那么程序會阻塞在這里，直到有一個連接過來，才能繼續向下執行。
而多路復用，允許我們只在事件發生時才將控制返回給程序，而其他時候內核都掛起進程，隨時待命。
核心：Nginx采用的 IO多路復用模型epoll
例子： Nginx 會注冊一個事件：“如果來自一個新客戶端的連接請求到來了，再通知我”，此后只有連接請求到來，服務器才會執行 accept() 來接收請求。又比如向上游服務器（比如 PHP-FPM）轉發請求，并等待請求返回時，這個處理的 worker 不會在這阻塞，它會在發送完請求后，注冊一個事件：“如果緩沖區接收到數據了，告訴我一聲，我再將它讀進來”，于是進程就空閑下來等待事件發生。
