驚群會造成一點資源的浪費，只要經過簡單的處理，不會導致任何業(yè)務異常。workerman中多個進程/線程嘗試去獲取客戶端鏈接時，如果發(fā)現鏈接已經被其它進程/線程認領，就什么也不做，沒有任何影響。

驚群
簡單的說 某個事件發(fā)生后，會喚醒多個正在等待該事件的進程/線程，造成一定的cpu資源的浪費

就像一個客人進餐館吃飯（代表一個客戶端鏈接到來），這時一些休息的服務生（接受鏈接的進程）看到客人來了趕緊起來去招呼客人，但是一個客人一個服務生就夠了，其它服務生看到客人已經被一個服務生搶先認領了，沒自己的事情了就又回去休息，造成浪費。

解決辦法
通常是通過鎖機制等，在任意時刻只讓一個進程/線程去接受客戶端鏈接。但是鎖機制也會造成cpu等資源的消耗及性能損耗，比起驚群的消耗誰大誰小目前沒有一個定論。

目前一些常見的服務器軟件有的是通過鎖機制來解決驚群的，比如nginx（nginx鎖機制默認是開啟的，可以關閉）；還有一些認為驚群對系統(tǒng)影響不大，沒有去處理，比如lighttpd。而apache一般沒有驚群效應，apache的進程模型是多個進程阻塞在accept上，目前的Linux內核已經解決了accpet驚群問題（經過本人實際測試確實如此）。

另外也可以通過SO_REUSEPORT選項解決驚群問題。workerman 3.2.1以上版本已經增加了此選項，需要設置worker->reusePort = true來激活。注意：workerman中此選項只在php7有效。

workerman
如同其它服務器軟件lighttpd等那樣，認為鎖機制或者單個進程/線程處理驚群會造成性能的下降，所以沒有處理驚群效應。
驚群效應只有在系統(tǒng)負載很低的時候明顯，隨著系統(tǒng)負載升高驚群效應減弱甚至消失。驚群造成的影響很小很小，相比復雜的業(yè)務，影響如同九牛一毛，可以忽略不計。

另外workerman主要是針對長連接應用，驚群只有在建立連接時才會出現，而長連接應用的特點就是不會頻繁建立連接，所以對于長連接應用，驚群效應完全可以忽略不計。

get