目錄
1.nginx管理/工作程序模式
2.「驚群」問題
為了支援現在流行的多cpu和多核架構，nginx使用了管理程序和工作程序的設計。架構設計如下圖所示：
管理程序為工作程序的父程序，負責外部指令的接收，工作程序的狀態監管，負載均衡等；工作程序負責客戶端請求的處理和響應，工作程序一般是按照cpu的核數配置的，並且可以和處理器一一繫結，降低程序間切換的開銷。
管理程序作為工作程序的管理程序和父程序，還可以帶來高可靠性：工作程序終止，管理程序可以及時啟動新的例項接替。這種模式的優點體現在一下3個方面：
apache的每個程序在乙個時刻只處理乙個請求，因此在多工處理階段，apache的程序數或執行緒數要設定的很多，這種情況下大量的程序間切換將帶來無謂的系統資源消耗。nginx的工作程序之間處理併發請求時幾乎沒有同步鎖的問題，而且工作程序採用全非同步的操作模式，處理速度快，占用記憶體小。事件驅動適合於io管理程序＋工作程序模式有很多優點，同時存在一些問題需要解決。密集型服務，多程序或者執行緒適合於
cpu密集型服務。所以
nginx
適合**伺服器，
apache適合後端應用伺服器
nginx裡的工作程序一般是按系統cpu核數配置的，有多少個cpu核心，就會配置多少個工作程序，工作程序啟動時就會利用fork函式建立多少個工作程序，並且所有的工作程序都監聽在nginx.conf內配置的監聽埠上，這樣可以充分利用多核機器的效能。
網路事件通過底層的events模組管理，當客戶端連線請求到來時，乙個新連線事件會上報，各個工作程序就會發生對事件的搶奪，這就是「驚群」問題。工作程序越多，問題越明顯，這會造成系統效能下降，所以，必須避免「驚群」問題。詳細來說，「驚群」問題的典型場景是這樣的：在沒有使用者請求的時候，所有的工作程序都在休眠，此時，乙個使用者向伺服器發起了連線請求，例如在epoll模式下，核心在收到了tcp的syn包時，會啟用所有休眠的工作程序，最先接收連線請求的工作程序可以成功建立新連線，其他工作程序的接收會失敗。這些失敗的喚醒是不必要的，引發了不必要的程序上下文切換，增加了系統開銷，這就是「驚群」問題。
nginx應用層制定了乙個機制解決這個問題：規定同一時刻只能有唯一乙個工作程序監聽web埠，這樣，新的連線事件只能喚醒唯一乙個工作程序。內部的實現實際上是使用了乙個程序間的同步鎖，工作程序每次喚醒都先嘗試這把鎖，保證同一時間只有乙個工作程序可以進入鎖，獲得鎖的程序設定監聽連線的讀事件，未能進入監聽鎖的工作程序則不監聽新連線事件，只處理已連線上的事件。
設定了連線事件監聽的程序在連線事件到來時會被喚醒並檢查系統變數，發現新連線佇列中有連線則釋放鎖，並呼叫對應事件的handler方法。這種技術既解決了「驚群」問題，也避免了乙個程序過長占用鎖使新連線得不到及時處理的問題，接收了乙個連線後，把連線放入佇列後馬上釋放鎖，如果恰巧有新連線馬上進來，則會由乙個新的工作程序接收連線，起到一定的負載均衡作用。放入佇列的請求事件會在後續階段處理。
Nginx程序模型
這篇主要是閱讀這篇博文的筆記。nginx採用的也是大部分http伺服器的做法，master，worker模型，基本的事件處理都是放在worker中，master負責一些全域性初始化，以及對worker的管理。nginx中的master和worker之間是通過socketpair來實現的，每次fork...
Nginx筆記 程序模型
nginx是乙個效能非常強的高併發處理伺服器，他可以支援百萬級併發的需求 當nginx啟動時候，master在80埠監聽，他的作用僅僅是監聽，與客戶端連線的是worker，例如現在在nginx.conf裡配置worker processes 3，那麼master就會fork三個worker程序用於處...
002 nginx的程序模型
一 概述 nginx的高效能是大家所了解的,nginx之所以擁有這麼好的效能和它的程序模型是分不開的.當nginx啟動的時候,它會以後臺程序的方式進行,然後nginx會啟動乙個master程序和多個worker程序.也就是說,nginx是採用多程序的方式程序的.現在我們需要了解一下master程序和...