問題：
nginx是乙個高效能網路併發伺服器，它的程序模型是，多程序模型，有乙個master程序，會啟動多個worker程序，（一般是根據cpu核心個數決定）然後每個程序又利用io多路復用技術，監聽多個socket，達到高併發的能力。
它存在乙個問題就在於，每個worker子程序都會去accept（）監聽套接字，當監聽套接字有乙個時間到來，那麼所有子程序都會被喚醒去獲取事件，但是最終只會有乙個進**正獲取到對應事件，這種效能浪費就叫做驚群。
解決方案：
其實在linux2.6中，核心已經解決了驚群問題，其處理方式就是，對於accept（），當核心接收到乙個客戶連線後，只會喚醒等待佇列上的乙個程序或執行緒。如果伺服器採用accept阻塞呼叫方式，在最新linux系統上，已經沒有驚群問題。
實際工程中，一般都是會直接使用select，poll，epoll等io多路復用機制，一般會阻塞在epoll，然後有連線到來才會去呼叫accept函式，在早起的linux版本中，對於epoll也是會全部喚醒，在最新的版本中，同樣也是只會喚醒等待佇列中的第乙個程序或執行緒。所以新版本部分的解決了epoll的驚群問題。
部分的解決，是說在一些場景下已經不存在驚群問題，但是在一些特殊場景下，依然有這個問題。
nginx的驚群問題
nginx採用master worker程序的模式，master負責解析配置，啟動worker程序和處理訊號，比如restart重啟worker程序，worker負責真正處理請求。當有多個worker程序時，乙個請求將被哪個worker程序處理呢？更具體一點，傳送請求的客戶端會與哪個worker程序...
詳解nginx驚群問題的解決方式
對於nginx的驚群問題，我們首先需要理解的是，在nginx啟動過程中，master程序會監聽配置檔案中指定的各個埠，然後master程序就會呼叫fork 方法建立各個子程序，根據程序的工作原理，子程序是會繼承父程序的全部記憶體資料以及監聽的埠的，也就是說worker程序在啟動之後也是會監聽各個埠的...
關於驚群問題
簡單說來，多執行緒 多程序 linux下執行緒程序也沒多大區別 等待同乙個socket事件，當這個事件發生時，這些執行緒 程序被同時喚醒，就是驚群。可以想見，效率很低下，許多程序被核心重新排程喚醒，同時去響應這乙個事件，當然只有乙個程序能處理事件成功，其他的程序在處理該事件失敗後重新休眠 也有其他選...