今天測試udp伺服器程序時發現log中記錄了當程序收到乙個請求後，會有多條失敗處理記錄，同時有一條成功處理記錄。伺服器程序使用sellect模式，通過fork四個子程序來監聽同乙個socket。
發現問題後初步懷疑是出現了驚群現象。但是，聽說現代核心已經解決了驚群問題，程式也可以確定也沒有問題，就奇怪問題發生在**了。
後來在網上一搜才知道，原來linux核心開發人員通過鎖機制解決了accept的驚群現象，但是對於sellect和epoll驚群問題並沒有解決，所以這種情形下驚群還會出現，也就是當多個程序通過sellect方式監聽同乙個socket的可讀狀態時，當該socket變為可讀，所有的監聽程序都會被喚醒並進行處理，但是對於udp伺服器，其中第乙個socket會一次性將資料讀完，導致其他程序再讀socket都返回了失敗。
網友給的解釋是對於select，資料是不互斥的，也就是需要多個程序來讀取資源。
因此，有使用fork+select搭建socket伺服器時要注意這個問題，很影響效能的。
關於驚群問題
簡單說來，多執行緒 多程序 linux下執行緒程序也沒多大區別 等待同乙個socket事件，當這個事件發生時，這些執行緒 程序被同時喚醒，就是驚群。可以想見，效率很低下，許多程序被核心重新排程喚醒，同時去響應這乙個事件，當然只有乙個程序能處理事件成功，其他的程序在處理該事件失敗後重新休眠 也有其他選...
nginx的驚群問題
問題 nginx是乙個高效能網路併發伺服器，它的程序模型是，多程序模型，有乙個master程序，會啟動多個worker程序，一般是根據cpu核心個數決定 然後每個程序又利用io多路復用技術，監聽多個socket，達到高併發的能力。它存在乙個問題就在於，每個worker子程序都會去accept 監聽套...
nginx的驚群問題
nginx採用master worker程序的模式，master負責解析配置，啟動worker程序和處理訊號，比如restart重啟worker程序，worker負責真正處理請求。當有多個worker程序時，乙個請求將被哪個worker程序處理呢？更具體一點，傳送請求的客戶端會與哪個worker程序...