目錄
1.Nginx管理/工作進程模式
爲了支持現在流行的多CPU和多核架構，Nginx使用了管理進程和工作進程的設計。架構設計如下圖所示：
管理進程爲工作進程的父進程，負責外部指令的接收，工作進程的狀態監管，負載均衡等；工作進程負責客戶端請求的處理和響應，工作進程一般是按照CPU的核數配置的，並且可以和處理器一一綁定，降低進程間切換的開銷。
管理進程作爲工作進程的管理進程和父進程，還可以帶來高可靠性：工作進程終止，管理進程可以及時啓動新的實例接替。這種模式的優點體現在一下3個方面：
- 充分利用多核系統的併發處理能力。Nginx中所有的工作進程都是平等的，並且可以在nginx.conf中將工作進程和處理器一一綁定，這樣配合負載均衡機制，不會讓某核繁忙，整體處理能力得到提高。
- 負載均衡：工作進程和管理進程通過進程間通信實現負載均衡，請求容易被分配到負載較輕的工作進程中，提高系統的整體性能。
- 方便狀態監管：管理進程任務很輕，只負責啓動、停止、監控工作進程，當某個工作進程不正常工作時，可立即啓動新的進程接管。同時，管理進程支持服務運行中的程序升級、配置項修改等操作，使系統整體具備了動態擴展性、動態可定製性、動態可進化性。
Apache的每個進程在一個時刻只處理一個請求，因此在多任務處理階段，Apache的進程數或線程數要設置的很多，這種情況下大量的進程間切換將帶來無謂的系統資源消耗。Nginx的工作進程之間處理併發請求時幾乎沒有同步鎖的問題，而且工作進程採用全異步的操作模式，處理速度快，佔用內存小。事件驅動適合於IO密集型服務，多進程或者線程適合於CPU密集型服務。所以Nginx適合代理服務器，apache適合後端應用服務器
2.“驚羣”問題
管理進程＋工作進程模式有很多優點，同時存在一些問題需要解決。
Nginx裏的工作進程一般是按系統CPU核數配置的，有多少個CPU核心，就會配置多少個工作進程，工作進程啓動時就會利用fork函數創建多少個工作進程，並且所有的工作進程都監聽在nginx.conf內配置的監聽端口上，這樣可以充分利用多核機器的性能。
網絡事件通過底層的events模塊管理，當客戶端連接請求到來時，一個新連接事件會上報，各個工作進程就會發生對事件的搶奪，這就是“驚羣”問題。工作進程越多，問題越明顯，這會造成系統性能下降，所以，必須避免“驚羣”問題。詳細來說，“驚羣”問題的典型場景是這樣的：在沒有用戶請求的時候，所有的工作進程都在休眠，此時，一個用戶向服務器發起了連接請求，例如在epoll模式下，內核在收到了TCP的SYN包時，會激活所有休眠的工作進程，最先接收連接請求的工作進程可以成功建立新連接，其他工作進程的接收會失敗。這些失敗的喚醒是不必要的，引發了不必要的進程上下文切換，增加了系統開銷，這就是“驚羣”問題。
Nginx應用層制定了一個機制解決這個問題：規定同一時刻只能有唯一一個工作進程監聽Web端口，這樣，新的連接事件只能喚醒唯一一個工作進程。內部的實現實際上是使用了一個進程間的同步鎖，工作進程每次喚醒都先嚐試這把鎖，保證同一時間只有一個工作進程可以進入鎖，獲得鎖的進程設置監聽連接的讀事件，未能進入監聽鎖的工作進程則不監聽新連接事件，只處理已連接上的事件。
設置了連接事件監聽的進程在連接事件到來時會被喚醒並檢查系統變量，發現新連接隊列中有連接則釋放鎖，並調用對應事件的handler方法。這種技術既解決了“驚羣”問題，也避免了一個進程過長佔用鎖使新連接得不到及時處理的問題，接收了一個連接後，把連接放入隊列後馬上釋放鎖，如果恰巧有新連接馬上進來，則會由一個新的工作進程接收連接，起到一定的負載均衡作用。放入隊列的請求事件會在後續階段處理。