什么是驚群效應？

第一次聽到的這個名詞的時候覺得很是有趣，不知道是個什么意思，總覺得又是奇怪的中文翻譯導致的。

復雜的說（來源于網絡）TLDR;

驚群效應（thundering herd）是指多進程（多線程）在同時阻塞等待同一個事件的時候（休眠狀態），如果等待的這個事件發生，那么他就會喚醒等待的所有進程（或者線程），但是最終卻只能有一個進程（線程）獲得這個時間的“控制權”，對該事件進行處理，而其他進程（線程）獲取“控制權”失敗，只能重新進入休眠狀態，這種現象和性能浪費就叫做驚群效應。

簡單的講（我的大白話）

有一道雷打下來，把很多人都吵醒了，但只有其中一個人去收衣服了。也就是：有一個請求過來了，把很多進程都喚醒了，但只有其中一個能最終處理。

原因&問題

說起來其實也簡單，多數時候為了提高應用的請求處理能力，會使用多進程（多線程）去監聽請求，當請求來時，因為都有能力處理，所以就都被喚醒了。

而問題就是，最終還是只能有一個進程能來處理。當請求多了，不停地喚醒、休眠、喚醒、休眠，做了很多的無用功，上下文切換又累，對吧。那怎么解決這個問題呢？下面就是今天要看的重點，我們看看 nginx 是如何解決這個問題的。

Nginx 架構

第一點我們需要了解 nginx 大致的架構是怎么樣的。nginx 將進程分為 master 和 worker 兩類，非常常見的一種 M-S 策略，也就是 master 負責統籌管理 worker，當然它也負責如：啟動、讀取配置文件，監聽處理各種信號等工作。

圖片來自：https://aosabook.org/en/v2/nginx.html

但是，第一個要注意的問題就出現了，master 的工作有且只有這些，對于請求來說它是不管的，就如同圖中所示，請求是直接被 worker 處理的。如此一來，請求應該被哪個 worker 處理呢？worker 內部又是如何處理請求的呢？

Nginx 使用 epoll

接下來我們就要知道 nginx 是如何使用 epoll 來處理請求的。下面可能會涉及到一些源碼的內容，但不用擔心，你不需要全部理解，只需要知道它們的作用就可以了。順便我會簡單描述一下我是如何去找到這些源碼的位置的。

Master 的工作

其實 Master 并不是毫無作為，至少端口是它來占的。

ngx_open_listening_sockets(ngx_cycle_t*cycle)
{
.....
for(i=0;ilistening.nelts;i++){
.....
if(bind(s,ls[i].sockaddr,ls[i].socklen)==-1){

if(listen(s,ls[i].backlog)==-1){
}

那么，根據我們 nginx.conf 的配置文件，看需要監聽哪個端口，于是就去 bind 的了，這里沒問題。

【發現源碼】這里我是直接在代碼里面搜 bind 方法去找的，因為我知道，不管你怎么樣，你總是要綁定端口的

然后是創建 worker 的，雖不起眼，但很關鍵。https://github.com/nginx/nginx/blob/b489ba83e9be446923facfe1a2fe392be3095d1f/src/os/unix/ngx_process.c#L186

ngx_spawn_process(ngx_cycle_t*cycle,ngx_spawn_proc_ptproc,void*data,
char*name,ngx_int_trespawn)
{
....
pid=fork();

【發現源碼】這里我直接搜 fork，整個項目里面需要 fork 的情況只有兩個地方，很快就找到了 worker

由于是 fork 創建的，也就是復制了一份 task_struct 結構。所以 master 的幾乎全部它都有。

Worker 的工作

Nginx 有一個分模塊的思想，它將不同功能分成了不同的模塊，而 epoll 自然就是在 ngx_epoll_module.c 中了

ngx_epoll_init(ngx_cycle_t*cycle,ngx_msec_ttimer)
{
ngx_epoll_conf_t*epcf;

epcf=ngx_event_get_conf(cycle->conf_ctx,ngx_epoll_module);

if(ep==-1){
ep=epoll_create(cycle->connection_n/2);

其他不重要，就連 epoll_ctl 和 epoll_wait 也不重要了，這里你需要知道的就是，從調用鏈路來看，是 worker 創建的 epoll 對象，也就是每個 worker 都有自己的 epoll 對象，而監聽的sokcet 是一樣的！

【發現源碼】這里更加直接，搜索 epoll_create 肯定就能找到

問題的關鍵

此時問題的關鍵基本就能了解了，每個 worker 都有處理能力，請求來了此時應該喚醒誰呢？講道理那不是所有 epoll 都會有事件，所有 worker 都 accept 請求？顯然這樣是不行的。那么 nginx 是如何解決的呢？

如何解決

解決方式一共有三種，下面我們一個個來看：

accept_mutex（應用層的解決方案）

EPOLLEXCLUSIVE（內核層的解決方案）

SO_REUSEPORT（內核層的解決方案）

accept_mutex

看到 mutex 可能你就知道了，鎖嘛！這也是對于高并發處理的 ”基操“ 遇事不決加鎖，沒錯，加鎖肯定能解決問題。

具體代碼就不展示了，其中細節很多，但本質很容易理解，就是當請求來了，誰拿到了這個鎖，誰就去處理。沒拿到的就不管了。鎖的問題很直接，除了慢沒啥不好的，但至少很公平。

EPOLLEXCLUSIVE

EPOLLEXCLUSIVE 是 2016 年 4.5+ 內核新添加的一個 epoll 的標識。它降低了多個進程/線程通過 epoll_ctl 添加共享 fd 引發的驚群概率，使得一個事件發生時，只喚醒一個正在 epoll_wait 阻塞等待喚醒的進程（而不是全部喚醒）。

關鍵是：每次內核只喚醒一個睡眠的進程處理資源

但，這個方案不是完美的解決了，它僅是降低了概率哦。為什么這樣說呢？相比于原來全部喚醒，那肯定是好了不少，降低了沖突。但由于本質來說 socket 是共享的，當前進程處理完成的時間不確定，在后面被喚醒的進程可能會發現當前的 socket 已經被之前喚醒的進程處理掉了。

SO_REUSEPORT

Nginx 在 1.9.1 版本加入了這個功能

其本質是利用了 Linux 的 reuseport 的特性，使用 reuseport 內核允許多個進程 listening socket 到同一個端口上，而從內核層面做了負載均衡，每次喚醒其中一個進程。

反應到 Nginx 上就是，每個 Worker 進程都創建獨立的 listening socket，監聽相同的端口，accept 時只有一個進程會獲得連接。效果就和下圖所示一樣。

而使用方式則是：

http{
server{
listen80reuseport;
server_namelocalhost;
#...
}
}

從官方的測試情況來看確實是厲害

當然，正所謂：完事無絕對，技術無銀彈。這個方案的問題在于內核是不知道你忙還是不忙的。只會無腦的丟給你。與之前的搶鎖對比，搶鎖的進程一定是不忙的，現在手上的工作都已經忙不過來了，沒機會去搶鎖了；而這個方案可能導致，如果當前進程忙不過來了，還是會只要根據 reuseport 的負載規則輪到你了就會發送給你，所以會導致有的請求被前面慢的請求卡住了。

總結

本文，從了解什么 ”驚群效應“ 到 nginx 架構和 epoll 處理的原理，最終分析三種不同的處理 “驚群效應” 的方案。分析到這里，我想你應該明白其實 nginx 這個多隊列服務模型是所存在的一些問題，只不過絕大多數場景已經完完全全夠用了。

審核編輯：湯梓紅