“據(jù)說”驚群問題已經(jīng)是一個很古老的問題了，并且在大多數(shù)系統(tǒng)中
已經(jīng)得到有效解決，但對我來說，仍舊是一個比較新的概念，因此有必要記錄一下。
什么是驚群 舉一個很簡單的例子，當你往一群鴿子中間扔一塊食物，雖然最終只有一個鴿子搶到食物，但所有鴿子都會被驚動來爭奪，沒有搶到食物的鴿子只好回去繼續(xù)睡覺，等待下一塊食物到來。這樣，每扔一塊食物，都會驚動所有的鴿子，即為驚群。對于操作系統(tǒng)來說，多個進程/線程在等待同一資源是，也會產(chǎn)生類似的效果，其結(jié)果就是每當資源可用，所有的進程/線程都來競爭資源，造成的后果：
1）系統(tǒng)對用戶進程/線程頻繁的做無效的調(diào)度、上下文切換，系統(tǒng)系能大打折扣。
2）為了確保只有一個線程得到資源，用戶必須對資源操作進行加鎖保護，進一步加大了系統(tǒng)開銷。
最常見的例子就是對于socket描述符的accept操作，當多個用戶進程/線程監(jiān)聽在同一個端口上時，由于實際只可能accept一次，因此就會產(chǎn)生驚群現(xiàn)象，當然前面已經(jīng)說過了，這個問題是一個古老的問題，新的操作系統(tǒng)內(nèi)核已經(jīng)解決了這一問題。
linux內(nèi)核解決驚群問題的方法 對于一些已知的驚群問題，內(nèi)核開發(fā)者增加了一個“互斥等待”選項。一個互斥等待的行為與睡眠基本類似，主要的不同點在于：
1）當一個等待隊列入口有 WQ_FLAG_EXCLUSEVE 標志置位, 它被添加到等待隊列的尾部. 沒有這個標志的入口項, 相反, 添加到開始.
2）當 wake_up 被在一個等待隊列上調(diào)用時, 它在喚醒第一個有 WQ_FLAG_EXCLUSIVE 標志的進程后停止。
也就是說，對于互斥等待的行為，比如如對一個listen后的socket描述符，多線程阻塞accept時，系統(tǒng)內(nèi)核只會喚醒所有正在等待此時間的隊列的第一個，隊列中的其他人則繼續(xù)等待下一次事件的發(fā)生，這樣就避免的多個線程同時監(jiān)聽同一個socket描述符時的驚群問題。
根據(jù)以上背景信息，我們來比較一下常見的Server端設(shè)計方案。
方案1：listen后，啟動多個線程(進程)，對此socket進行監(jiān)聽（僅阻塞accept方式不驚群）。
方案2：主線程負責監(jiān)聽，通過線程池方式處理連接。（通常的方法）
方案3：主線程負責監(jiān)聽，客戶端連接上來后由主線程分配實際的端口，客戶端根據(jù)此端口重新連接，然后處理數(shù)據(jù)。
先考慮客戶端單連接的情況：
方案1：每當有新的連接到來時，系統(tǒng)內(nèi)核會從隊列中以FIFO的方式選擇一個監(jiān)聽線程來服務(wù)此連接，因此可以充分發(fā)揮系統(tǒng)的系能并且多線程負載均衡。對于單連接的場景，這種方案無疑是非常優(yōu)越的。遺憾的是，對于select、epoll，內(nèi)核目前無法解決驚群問題。
(nginx對于驚群問題的解決方法)方案2：由于只有一個線程在監(jiān)聽，其瞬時的并發(fā)處理連接請求的能力必然不如多線程。同時，需要對線程池做調(diào)度管理，必然涉及資源共享訪問，相對于方案一來說管理成本要增加不少，代碼復(fù)雜度提高，性能也有所下降。
方案3：與方案2有不少類似的地方，其優(yōu)勢是不需要做線程調(diào)度。缺點是增加了主線程的負擔，除了接收連接外還需要發(fā)送數(shù)據(jù)，而且需要兩次連接，孰優(yōu)孰劣，有待測試。
再考慮客戶端多連接的情況：對于數(shù)據(jù)傳輸類的應(yīng)用，為了充分利用帶寬，往往會開啟多個連接來傳輸數(shù)據(jù)，連接之間的數(shù)據(jù)有相互依賴性，因此Server端要想很好的維護這種依賴性，把同一個客戶端的所有連接放在一個線程中處理是非常有必要的。
A、同一客戶端在一個線程中處理方案1：如果沒有更底層的解決方案的話，Server則需要維護一個全局列表，來記錄當前連接請求該由哪個線程處理。多線程需要同時競爭一個全局資源，似乎有些不妙。
方案2：主線程負責監(jiān)聽并分發(fā)，因此與單連接相比沒有帶來額外的性能開銷。僅僅會造成主線程忙于更多的連接請求。
方案3：較單線程來說，主線程工作量沒有任何增加，由于多連接而造成的額外開銷由實際工作線程分擔，因此對于這種場景，方案3似乎是最佳選擇。
B、同一客戶端在不同線程中處理方案1：同樣需要競爭資源。
方案2：沒理由。
方案3：不可能。
另外：
(《UNIX網(wǎng)絡(luò)編程》第三版是在第30章)
讀《UNIX網(wǎng)絡(luò)編程》第二版的第一卷時，發(fā)現(xiàn)作者在第27章“客戶-服務(wù)器程序其它設(shè)計方法”中的27.6節(jié)“TCP預(yù)先派生子進程服務(wù)器程序，accept無上鎖保護”中提到了一種由子進程去競爭客戶端連接的設(shè)計方法，用偽碼描述如下:
服務(wù)器主進程:
| listen_fd = socket(...);
bind(listen_fd, ...);
listen(listen_fd, ...);
pre_fork_children(...);
close(listen_fd);
wait_children_die(...);
|
服務(wù)器服務(wù)子進程:
| while (1) {
conn_fd = accept(listen_fd, ...);
do_service(conn_fd, ...);
}
|
初 識上述代碼，真有眼前一亮的感覺，也正如作者所說，以上代碼確實很少見（反正我讀此書之前是確實沒見過）。作者真是構(gòu)思精巧，巧妙地繞過了常見的預(yù)先創(chuàng)建 子進程的多進程服務(wù)器當主服務(wù)進程接收到新的連接必須想辦法將這個連接傳遞給服務(wù)子進程的“陷阱”，上述代碼通過共享的傾聽套接字，由子進程主動地去向內(nèi) 核“索要”連接套接字，從而避免了用UNIX域套接字傳遞文件描述符的“淫技”。
不過，當接著往下讀的時候，作者談到了“驚群” （Thundering herd)問題。所謂的“驚群”就是，當很多進程都阻塞在accept系統(tǒng)調(diào)用的時候，即使只有一個新的連接達到，內(nèi)核也會喚醒所有阻塞在accept上 的進程，這將給系統(tǒng)帶來非常大的“震顫”，降低系統(tǒng)性能。
除了這個問題，accept還必須是原子操作。為此，作者在接下來的27.7節(jié)講述了加了互斥鎖的版本：
| while (1) {
lock(...);
conn_fd = accept(listen_fd, ...);
unlock(...);
do_service(conn_fd, ...);
}
|
原 子操作的問題算是解決了，那么“驚群”呢？文中只是提到在Solaris系統(tǒng)上當子進程數(shù)由75變成90后，CPU時間顯著增加，并且作者認為這是因為進 程過多，導(dǎo)致內(nèi)存互換。對“驚群”問題回答地十分含糊。通過比較書中圖27.2的第4列和第7列的內(nèi)容，我們可以肯定“真兇”絕對不是“內(nèi)存對換”。
“元兇”到底是誰？
仔 細分析一下，加鎖真的有助于“驚群”問題么？不錯，確實在同一時間只有一個子進程在調(diào)用accept，其它子進程都阻塞在了lock語句，但是，當 accept返回并unlock之后呢？unlock肯定是要喚醒阻塞在這個鎖上的進程的，不過誰都沒有規(guī)定是喚醒一個還是喚醒多個。所以，潛在的“驚 群”問題還是存在，只不過換了個地方，換了個形式。而造成Solaris性能驟降的“罪魁禍首”很有可能就是“驚群”問題。
崩潰了！這么說所有的鎖都有可能產(chǎn)生驚群問題了？
似乎真的是這樣，所以
減少鎖的使用很重要。特別是在競爭比較激烈的地方。
作者在27.9節(jié)所實現(xiàn)的“傳遞文件描述符”版本的服務(wù)器就有效地克服了“驚群”問題，在現(xiàn)實的服務(wù)器實現(xiàn)中，最常用的也是此節(jié)所提到的基于“分配”形式。
把“競爭”換成“分配”是避免“驚群”問題的有效方法，但是
也不要忽視“分配”的“均衡”問題，不然后果可能更加嚴重哦！