https://blog.csdn.net/lyztyycode/article/details/78648798?locationNum=6&fps=1

linux驚群效應(yīng)

詳細(xì)的介紹什么是驚群，驚群在線程和進(jìn)程中的具體表現(xiàn)，驚群的系統(tǒng)消耗和驚群的處理方法。

1、驚群效應(yīng)是什么？

驚群效應(yīng)也有人叫做雷鳴群體效應(yīng)，不過(guò)叫什么，簡(jiǎn)言之，驚群現(xiàn)象就是多進(jìn)程（多線程）在同時(shí)阻塞等待同一個(gè)事件的時(shí)候（休眠狀態(tài)），如果等待的這個(gè)事件發(fā)生，那么他就會(huì)喚醒等待的所有進(jìn)程（或者線程），但是最終卻只可能有一個(gè)進(jìn)程（線程）獲得這個(gè)時(shí)間的“控制權(quán)”，對(duì)該事件進(jìn)行處理，而其他進(jìn)程（線程）獲取“控制權(quán)”失敗，只能重新進(jìn)入休眠狀態(tài)，這種現(xiàn)象和性能浪費(fèi)就叫做驚群。 為了更好的理解何為驚群，舉一個(gè)很簡(jiǎn)單的例子，當(dāng)你往一群鴿子中間扔一粒谷子，所有的各自都被驚動(dòng)前來(lái)?yè)寠Z這粒食物，但是最終注定只可能有一個(gè)鴿子滿意的搶到食物，沒(méi)有搶到的鴿子只好回去繼續(xù)睡覺(jué)，等待下一粒谷子的到來(lái)。這里鴿子表示進(jìn)程（線程），那粒谷子就是等待處理的事件。
看一下：WIKI的雷鳴群體效應(yīng)的解釋

2.驚群效應(yīng)到底消耗了什么？

我想你應(yīng)該也會(huì)有跟我一樣的問(wèn)題，那就是驚群效應(yīng)到底消耗了什么？ ? ???（1）、系統(tǒng)對(duì)用戶進(jìn)程/線程頻繁地做無(wú)效的調(diào)度，上下文切換系統(tǒng)性能大打折扣。 （2）、為了確保只有一個(gè)線程得到資源，用戶必須對(duì)資源操作進(jìn)行加鎖保護(hù)，進(jìn)一步加大了系統(tǒng)開(kāi)銷。 是不是還是覺(jué)得不夠深入，概念化？看下面： ? ? ???? *1、上下文切換（context? switch）過(guò)高會(huì)導(dǎo)致cpu像個(gè)搬運(yùn)工，頻繁地在寄存器和運(yùn)行隊(duì)列之間奔波，更多的時(shí)間花在了進(jìn)程（線程）切換，而不是在真正工作的進(jìn)程（線程）上面。直接的消耗包括cpu寄存器要保存和加載（例如程序計(jì)數(shù)器）、系統(tǒng)調(diào)度器的代碼需要執(zhí)行。間接的消耗在于多核cache之間的共享數(shù)據(jù)。 看一下：wiki上下文切換 *2、通過(guò)鎖機(jī)制解決驚群效應(yīng)是一種方法，在任意時(shí)刻只讓一個(gè)進(jìn)程（線程）處理等待的事件。但是鎖機(jī)制也會(huì)造成cpu等資源的消耗和性能損耗。目前一些常見(jiàn)的服務(wù)器軟件有的是通過(guò)鎖機(jī)制解決的，比如nginx（它的鎖機(jī)制是默認(rèn)開(kāi)啟的，可以關(guān)閉）；還有些認(rèn)為驚群對(duì)系統(tǒng)性能影響不大，沒(méi)有去處理，比如lighttpd。

3.驚群效應(yīng)的廬山真面目。

讓我們從進(jìn)程和線程兩個(gè)方面來(lái)揭開(kāi)驚群效應(yīng)的廬山真面目：

*1）accept（）驚群：

首先讓我們先來(lái)考慮一個(gè)場(chǎng)景： ? ? ? ??主進(jìn)程創(chuàng)建了socket、bind、listen之后，fork()出來(lái)多個(gè)進(jìn)程，每個(gè)子進(jìn)程都開(kāi)始循環(huán)處理（accept）這個(gè)listen_fd。每個(gè)進(jìn)程都阻塞在accept上，當(dāng)一個(gè)新的連接到來(lái)時(shí)候，所有的進(jìn)程都會(huì)被喚醒，但是其中只有一個(gè)進(jìn)程會(huì)接受成功，其余皆失敗，重新休眠。 那么這個(gè)問(wèn)題真的存在嗎？ ? ? ? ?歷史上，Linux的accpet確實(shí)存在驚群?jiǎn)栴}，但現(xiàn)在的內(nèi)核都解決該問(wèn)題了。即，當(dāng)多個(gè)進(jìn)程/線程都阻塞在對(duì)同一個(gè)socket的接受調(diào)用上時(shí)，當(dāng)有一個(gè)新的連接到來(lái)，內(nèi)核只會(huì)喚醒一個(gè)進(jìn)程，其他進(jìn)程保持休眠，壓根就不會(huì)被喚醒。 ? ? ?? 不妨寫個(gè)程序測(cè)試一下，眼見(jiàn)為實(shí)： fork_thunder_herd.c: [cpp]?view plaincopy

#include<stdio.h>??

#include<stdlib.h>??

#include<sys/types.h>??

#include<sys/socket.h>??

#include<sys/wait.h>??

#include<string.h>??

#include<netinet/in.h>??

#include<unistd.h>??

??

#define?PROCESS_NUM?10??

int?main()??

{??

????int?fd?=?socket(PF_INET,?SOCK_STREAM,?0);??

????int?connfd;??

????int?pid;??

??

????char?sendbuff[1024];??

????struct?sockaddr_in?serveraddr;??

????serveraddr.sin_family?=?AF_INET;??

????serveraddr.sin_addr.s_addr?=?htonl(INADDR_ANY);??

????serveraddr.sin_port?=?htons(1234);??

????bind(fd,?(struct?sockaddr?*)&serveraddr,?sizeof(serveraddr));??

????listen(fd,?1024);??

????int?i;??

????for(i?=?0;?i?<?PROCESS_NUM;?++i){??

????????pid?=?fork();??

????????if(pid?==?0){??

????????????while(1){??

????????????????connfd?=?accept(fd,?(struct?sockaddr?*)NULL,?NULL);??

????????????????snprintf(sendbuff,?sizeof(sendbuff),?"接收到accept事件的進(jìn)程PID?=?%d\n",?getpid());??

??

????????????????send(connfd,?sendbuff,?strlen(sendbuff)+1,?0);??

????????????????printf("process?%d?accept?success\n",?getpid());??

????????????????close(connfd);??

????????????}??

????????}??

????}??

????//int?status;??

????wait(0);??

????return?0;??

}??

這個(gè)程序模擬上面的場(chǎng)景，當(dāng)我們用telnet連接該服務(wù)器程序時(shí)，會(huì)看到只返回一個(gè)進(jìn)程pid，即只有一個(gè)進(jìn)程被喚醒。 我們用strace -f來(lái)追蹤fork子進(jìn)程的執(zhí)行： 編譯：cc fork_thunder_herd.c -o server ? ? ? ? ???一個(gè)終端執(zhí)行strace -f? ./server??你會(huì)看到如下結(jié)果（只截取部分可以說(shuō)明問(wèn)題的截圖，減小篇幅）： 這里我們首先看到系統(tǒng)創(chuàng)建了十個(gè)進(jìn)程。下面這張圖你會(huì)看出十個(gè)進(jìn)程阻塞在accept這個(gè)系統(tǒng)調(diào)用上面： 接下來(lái)在另一個(gè)終端執(zhí)行telnet 127.0.0.1 1234：

很明顯當(dāng)telnet連接的時(shí)候只有一個(gè)進(jìn)程accept成功,你會(huì)不會(huì)和我有同樣的疑問(wèn)，就是會(huì)不會(huì)內(nèi)核中喚醒了所有的進(jìn)程只是沒(méi)有獲取到資源失敗了，就好像驚群被“隱藏”？

這個(gè)問(wèn)題很好證明，我們修改一下代碼：

[cpp]?view plaincopy

connfd?=?accept(fd,?(struct?sockaddr?*)NULL,?NULL);??

if(connfd?==?0){??

??

????snprintf(sendbuff,?sizeof(sendbuff),?"接收到accept事件的進(jìn)程PID?=?%d\n",?getpid());??

??

????send(connfd,?sendbuff,?strlen(sendbuff)+1,?0);??

????printf("process?%d?accept?success\n",?getpid());??

????close(connfd);??

}else{??

????printf("process?%d?accept?a?connection?failed:?%s\n",?getpid(),?strerror(errno));??

????close(connfd);??

}??

沒(méi)錯(cuò)，就是增加了一個(gè)accept失敗的返回信息，按照上面的步驟運(yùn)行，這里我就不截圖了，我只告訴你運(yùn)行結(jié)果與上面的運(yùn)行結(jié)果無(wú)異，增加的失敗信息并沒(méi)有輸出，也就說(shuō)明了這里并沒(méi)有發(fā)生驚群，所以注意阻塞和驚群的喚醒的區(qū)別。

Google了一下：其實(shí)在linux2.6版本以后，linux內(nèi)核已經(jīng)解決了accept（）函數(shù)的“驚群”現(xiàn)象，大概的處理方式就是，當(dāng)內(nèi)核接收到一個(gè)客戶連接后，只會(huì)喚醒等待隊(duì)列上的第一個(gè)進(jìn)程（線程）,所以如果服務(wù)器采用accept阻塞調(diào)用方式，在最新的linux系統(tǒng)中已經(jīng)沒(méi)有“驚群效應(yīng)”了

accept函數(shù)的驚群解決了，下面來(lái)讓我們看看存在驚群現(xiàn)象的另一種情況：epoll驚群

*2）epoll驚群：

概述：如果多個(gè)進(jìn)程/線程阻塞在監(jiān)聽(tīng)同一個(gè)監(jiān)聽(tīng)socket?fd的epoll_wait上，當(dāng)有一個(gè)新的連接到來(lái)時(shí)，所有的進(jìn)程都會(huì)被喚醒。
同樣讓我們假設(shè)一個(gè)場(chǎng)景：
主進(jìn)程創(chuàng)建socket，bind，listen后，將該socket加入到epoll中，然后fork出多個(gè)子進(jìn)程，每個(gè)進(jìn)程都阻塞在epoll_wait上，如果有事件到來(lái)，則判斷該事件是否是該socket上的事件如果是，說(shuō)明有新的連接到來(lái)了，則進(jìn)行接受操作。為了簡(jiǎn)化處理，忽略后續(xù)的讀寫以及對(duì)接受返回的新的套接字的處理，直接斷開(kāi)連接。
那么，當(dāng)新的連接到來(lái)時(shí)，是否每個(gè)阻塞在epoll_wait上的進(jìn)程都會(huì)被喚醒呢？
很多博客中提到，測(cè)試表明雖然epoll_wait不會(huì)像接受那樣只喚醒一個(gè)進(jìn)程/線程，但也不會(huì)把所有的進(jìn)程/線程都喚醒。這究竟是問(wèn)什么呢？看一下：多進(jìn)程epoll和“驚群”

我們還是眼見(jiàn)為實(shí)，一步步解決上面的疑問(wèn)：

代碼實(shí)例：epoll_thunder_herd.c:

[cpp]?view plaincopy

#include<stdio.h>??

#include<sys/types.h>??

#include<sys/socket.h>??

#include<unistd.h>??

#include<sys/epoll.h>??

#include<netdb.h>??

#include<stdlib.h>??

#include<fcntl.h>??

#include<sys/wait.h>??

#include<errno.h>??

#define?PROCESS_NUM?10??

#define?MAXEVENTS?64??

//socket創(chuàng)建和綁定??

int?sock_creat_bind(char?*?port){??

????int?sock_fd?=?socket(AF_INET,?SOCK_STREAM,?0);??

????struct?sockaddr_in?serveraddr;??

????serveraddr.sin_family?=?AF_INET;??

????serveraddr.sin_port?=?htons(atoi(port));??

????serveraddr.sin_addr.s_addr?=?htonl(INADDR_ANY);??

??

????bind(sock_fd,?(struct?sockaddr?*)&serveraddr,?sizeof(serveraddr));??

????return?sock_fd;??

}??

//利用fcntl設(shè)置文件或者函數(shù)調(diào)用的狀態(tài)標(biāo)志??

int?make_nonblocking(int?fd){??

????int?val?=?fcntl(fd,?F_GETFL);??

????val?|=?O_NONBLOCK;??

????if(fcntl(fd,?F_SETFL,?val)?<?0){??

????????perror("fcntl?set");??

????????return?-1;??

????}??

????return?0;??

}??

??

int?main(int?argc,?char?*argv[])??

{??

????int?sock_fd,?epoll_fd;??

????struct?epoll_event?event;??

????struct?epoll_event?*events;??

??????????

????if(argc?<?2){??

????????printf("usage:?[port]?%s",?argv[1]);??

????????exit(1);??

????}??

?????if((sock_fd?=?sock_creat_bind(argv[1]))?<?0){??

????????perror("socket?and?bind");??

????????exit(1);??

????}??

????if(make_nonblocking(sock_fd)?<?0){??

????????perror("make?non?blocking");??

????????exit(1);??

????}??

????if(listen(sock_fd,?SOMAXCONN)?<?0){??

????????perror("listen");??

????????exit(1);??

????}??

????if((epoll_fd?=?epoll_create(MAXEVENTS))<?0){??

????????perror("epoll_create");??

????????exit(1);??

????}??

????event.data.fd?=?sock_fd;??

????event.events?=?EPOLLIN;??

????if(epoll_ctl(epoll_fd,?EPOLL_CTL_ADD,?sock_fd,?&event)?<?0){??

????????perror("epoll_ctl");??

????????exit(1);??

????}??

????/*buffer?where?events?are?returned*/??

????events?=?calloc(MAXEVENTS,?sizeof(event));??

????int?i;??

????for(i?=?0;?i?<?PROCESS_NUM;?++i){??

????????int?pid?=?fork();??

????????if(pid?==?0){??

????????????while(1){??

????????????????int?num,?j;??

????????????????num?=?epoll_wait(epoll_fd,?events,?MAXEVENTS,?-1);??

????????????????printf("process?%d?returnt?from?epoll_wait\n",?getpid());??

????????????????sleep(2);??

????????????????for(i?=?0;?i?<?num;?++i){??

????????????????????if((events[i].events?&?EPOLLERR)?||?(events[i].events?&?EPOLLHUP)?||?(!(events[i].events?&?EPOLLIN))){??

????????????????????????fprintf(stderr,?"epoll?error\n");??

????????????????????????close(events[i].data.fd);??

????????????????????????continue;??

????????????????????}else?if(sock_fd?==?events[i].data.fd){??

????????????????????????//收到關(guān)于監(jiān)聽(tīng)套接字的通知，意味著一盒或者多個(gè)傳入連接??

????????????????????????struct?sockaddr?in_addr;??

????????????????????????socklen_t?in_len?=?sizeof(in_addr);??

????????????????????????if(accept(sock_fd,?&in_addr,?&in_len)?<?0){??

????????????????????????????printf("process?%d?accept?failed!\n",?getpid());??

????????????????????????}else{??

????????????????????????????printf("process?%d?accept?successful!\n",?getpid());??

????????????????????????}??

????????????????????}??

????????????????}??

????????????}??

????????}??

????}??

????wait(0);??

????free(events);??

????close(sock_fd);??

????return?0;??

}??

上面的代碼編譯gcc epoll_thunder_herd.c -o server?

一個(gè)終端運(yùn)行代碼 ./server 1234? 另一個(gè)終端telnet 127.0.0.1 1234

運(yùn)行結(jié)果：

這里我們看到只有一個(gè)進(jìn)程返回了，似乎并沒(méi)有驚群效應(yīng)，讓我們用strace -f? ./server 8888追蹤執(zhí)行過(guò)程（這里只給出telnet之后的截圖，之前的截圖參考accept，不同的就是進(jìn)程阻塞在epoll_wait）

截圖（部分）：

運(yùn)行結(jié)果顯示了部分個(gè)進(jìn)程被喚醒了，返回了“process accept failed”只是后面因?yàn)槟承┰蚴×恕Ｋ赃@里貌似存在部分“驚群”。

怎么判斷發(fā)生了驚群呢？

我們根據(jù)strace的返回信息可以確定:

1)系統(tǒng)只會(huì)讓一個(gè)進(jìn)程真正的接受這個(gè)連接，而剩余的進(jìn)程會(huì)獲得一個(gè)EAGAIN信號(hào)。圖中有體現(xiàn)。

2）通過(guò)返回結(jié)果和進(jìn)程執(zhí)行的系統(tǒng)調(diào)用判斷。

這究竟是什么原因?qū)е碌哪?#xff1f;

看我們的代碼，看似部分進(jìn)程被喚醒了，而事實(shí)上其余進(jìn)程沒(méi)有被喚醒的原因是因?yàn)槟硞€(gè)進(jìn)程已經(jīng)處理完這個(gè)事件，無(wú)需喚醒其他進(jìn)程，你可以在epoll獲知這個(gè)事件的時(shí)候sleep（2）；這樣所有的進(jìn)程都會(huì)被喚起。看下面改正后的代碼結(jié)果更加清晰：

代碼修改：

[cpp]?view plaincopy

num?=?epoll_wait(epoll_fd,?events,?MAXEVENTS,?-1);??

printf("process?%d?returnt?from?epoll_wait\n",?getpid());??

sleep(2);??

運(yùn)行結(jié)果：

如圖所示：所有的進(jìn)程都被喚醒了。所以epoll_wait的驚群確實(shí)存在。

為什么內(nèi)核處理了accept的驚群，卻不處理epoll_wait的驚群呢？

我想，應(yīng)該是這樣的：
accept確實(shí)應(yīng)該只能被一個(gè)進(jìn)程調(diào)用成功，內(nèi)核很清楚這一點(diǎn)。但epoll不一樣，他監(jiān)聽(tīng)的文件描述符，除了可能后續(xù)被accept調(diào)用外，還有可能是其他網(wǎng)絡(luò)IO事件的，而其他IO事件是否只能由一個(gè)進(jìn)程處理，是不一定的，內(nèi)核不能保證這一點(diǎn)，這是一個(gè)由用戶決定的事情，例如可能一個(gè)文件會(huì)由多個(gè)進(jìn)程來(lái)讀寫。所以，對(duì)epoll的驚群，內(nèi)核則不予處理。

*3）線程驚群：

進(jìn)程的驚群已經(jīng)介紹的很詳細(xì)了，這里我就舉一個(gè)線程驚群的簡(jiǎn)單例子，我就截取上次紅包代碼中的代碼片段，如下 [cpp]?view plaincopy

printf("初始的紅包情況：<個(gè)數(shù)：%d??金額：%d.%02d>\n",item.number,?item.total/100,?item.total%100);??

pthread_cond_broadcast(&temp.cond);//紅包包好后喚醒所有線程搶紅包??

pthread_mutex_unlock(&temp.mutex);//解鎖??

sleep(1);??

沒(méi)錯(cuò)你可能已經(jīng)注意到了，pthread_cond_broadcast()在資源準(zhǔn)備好以后，或者你再編寫程序的時(shí)候設(shè)置的某個(gè)事件滿足時(shí)它會(huì)喚醒隊(duì)列上的所有線程去處理這個(gè)事件，但是只有一個(gè)線程會(huì)真正的獲得事件的“控制權(quán)”。 解決方法之一就是加鎖。下面我們來(lái)看一看解決或者避免驚群都有哪些方法？

4.我們?cè)趺唇鉀Q“驚群”呢？你有什么高見(jiàn)？

這里通常代碼加鎖的處理機(jī)制我就不詳述了，來(lái)看一下常見(jiàn)軟件的處理機(jī)制和linux最新的避免和解決的辦法

（1）、Nginx的解決：

如上所述，如果采用epoll，則仍然存在該問(wèn)題，nginx就是這種場(chǎng)景的一個(gè)典型，我們接下來(lái)看看其具體的處理方法。 nginx的每個(gè)worker進(jìn)程都會(huì)在函數(shù)ngx_process_events_and_timers()中處理不同的事件，然后通過(guò)ngx_process_events()封裝了不同的事件處理機(jī)制，在Linux上默認(rèn)采用epoll_wait()。 在主要ngx_process_events_and_timers()函數(shù)中解決驚群現(xiàn)象。 [cpp]?view plaincopy

void?ngx_process_events_and_timers(ngx_cycle_t?*cycle)??

{??

????...?...??

????//?是否通過(guò)對(duì)accept加鎖來(lái)解決驚群?jiǎn)栴}，需要工作線程數(shù)>1且配置文件打開(kāi)accetp_mutex??

????if?(ngx_use_accept_mutex)?{??

????????//?超過(guò)配置文件中最大連接數(shù)的7/8時(shí)，該值大于0，此時(shí)滿負(fù)荷不會(huì)再處理新連接，簡(jiǎn)單負(fù)載均衡??

????????if?(ngx_accept_disabled?>?0)?{??

????????????ngx_accept_disabled--;??

????????}?else?{??

????????????//?多個(gè)worker僅有一個(gè)可以得到這把鎖。獲取鎖不會(huì)阻塞過(guò)程，而是立刻返回，獲取成功的話??

????????????//?ngx_accept_mutex_held被置為1。拿到鎖意味著監(jiān)聽(tīng)句柄被放到本進(jìn)程的epoll中了，如果??

????????????//?沒(méi)有拿到鎖，則監(jiān)聽(tīng)句柄會(huì)被從epoll中取出。??

????????????if?(ngx_trylock_accept_mutex(cycle)?==?NGX_ERROR)?{??

????????????????return;??

????????????}??

????????????if?(ngx_accept_mutex_held)?{??

????????????????//?此時(shí)意味著ngx_process_events()函數(shù)中，任何事件都將延后處理，會(huì)把a(bǔ)ccept事件放到??

????????????????//?ngx_posted_accept_events鏈表中，epollin|epollout事件都放到ngx_posted_events鏈表中??

????????????????flags?|=?NGX_POST_EVENTS;??

????????????}?else?{??

????????????????//?拿不到鎖，也就不會(huì)處理監(jiān)聽(tīng)的句柄，這個(gè)timer實(shí)際是傳給epoll_wait的超時(shí)時(shí)間，修改??

????????????????//?為最大ngx_accept_mutex_delay意味著epoll_wait更短的超時(shí)返回，以免新連接長(zhǎng)時(shí)間沒(méi)有得到處理??

????????????????if?(timer?==?NGX_TIMER_INFINITE?||?timer?>?ngx_accept_mutex_delay)?{??

????????????????????timer?=?ngx_accept_mutex_delay;??

????????????????}??

????????????}??

????????}??

????}??

????...?...??

????(void)?ngx_process_events(cycle,?timer,?flags);???//?實(shí)際調(diào)用ngx_epoll_process_events函數(shù)開(kāi)始處理??

????...?...??

????if?(ngx_posted_accept_events)?{?//如果ngx_posted_accept_events鏈表有數(shù)據(jù)，就開(kāi)始accept建立新連接??

????????ngx_event_process_posted(cycle,?&ngx_posted_accept_events);??

????}??

??

????if?(ngx_accept_mutex_held)?{?//釋放鎖后再處理下面的EPOLLIN?EPOLLOUT請(qǐng)求??

????????ngx_shmtx_unlock(&ngx_accept_mutex);??

????}??

??

????if?(delta)?{??

????????ngx_event_expire_timers();??

????}??

??

????ngx_log_debug1(NGX_LOG_DEBUG_EVENT,?cycle->log,?0,?"posted?events?%p",?ngx_posted_events);??

????//?然后再處理正常的數(shù)據(jù)讀寫請(qǐng)求。因?yàn)檫@些請(qǐng)求耗時(shí)久，所以在ngx_process_events里NGX_POST_EVENTS標(biāo)??

????//?志將事件都放入ngx_posted_events鏈表中，延遲到鎖釋放了再處理。??

}}??

具體的解釋參考：nginx處理驚群詳解

（2）、SO_REUSEPORT

Linux內(nèi)核的3.9版本帶來(lái)了SO_REUSEPORT特性，該特性支持多個(gè)進(jìn)程或者線程綁定到同一端口，提高服務(wù)器程序的性能，允許多個(gè)套接字bind()以及l(fā)isten()同一個(gè)TCP或UDP端口，并且在內(nèi)核層面實(shí)現(xiàn)負(fù)載均衡。

在未開(kāi)啟SO_REUSEPORT的時(shí)候，由一個(gè)監(jiān)聽(tīng)socket將新接收的連接請(qǐng)求交給各個(gè)工作者處理，看圖示：

在使用SO_REUSEPORT后，多個(gè)進(jìn)程可以同時(shí)監(jiān)聽(tīng)同一個(gè)IP：端口，然后由內(nèi)核決定將新鏈接發(fā)送給哪個(gè)進(jìn)程，顯然會(huì)降低每個(gè)工人接收新鏈接時(shí)鎖競(jìng)爭(zhēng)
下面讓我們好好比較一下多進(jìn)程（線程）服務(wù)器編程傳統(tǒng)方法和使用SO_REUSEPORT的區(qū)別

運(yùn)行在Linux系統(tǒng)上的網(wǎng)絡(luò)應(yīng)用程序，為了利用多核的優(yōu)勢(shì)，一般使用以下典型的多進(jìn)程（多線程）服務(wù)器模型：

1.單線程listener/accept，多個(gè)工作線程接受任務(wù)分發(fā)，雖然CPU工作負(fù)載不再成為問(wèn)題，但是仍然存在問(wèn)題：

? ? ?? （1）、單線程listener（圖一），在處理高速率海量連接的時(shí)候，一樣會(huì)成為瓶頸

? ? ? ? （2）、cpu緩存行丟失套接字結(jié)構(gòu)現(xiàn)象嚴(yán)重。

2.所有工作線程都accept（）在同一個(gè)服務(wù)器套接字上呢？一樣存在問(wèn)題：

? ? ? ? （1）、多線程訪問(wèn)server socket鎖競(jìng)爭(zhēng)嚴(yán)重。

? ? ? ? （2）、高負(fù)載情況下，線程之間的處理不均衡，有時(shí)高達(dá)3：1。

? ? ? ? （3）、導(dǎo)致cpu緩存行跳躍（cache line bouncing）。

? ? ? ? （4）、在繁忙cpu上存在較大延遲。

上面兩種方法共同點(diǎn)就是很難做到cpu之間的負(fù)載均衡，隨著核數(shù)的提升，性能并沒(méi)有提升。甚至服務(wù)器的吞吐量CPS（Connection Per Second）會(huì)隨著核數(shù)的增加呈下降趨勢(shì)。

下面我們就來(lái)看看SO_REUSEPORT解決了什么問(wèn)題：

? ? ? ? （1）、允許多個(gè)套接字bind()/listen()同一個(gè)tcp/udp端口。每一個(gè)線程擁有自己的服務(wù)器套接字，在服務(wù)器套接字上沒(méi)有鎖的競(jìng)爭(zhēng)。

? ? ? ? （2）、內(nèi)核層面實(shí)現(xiàn)負(fù)載均衡

? ? ? ? （3）、安全層面，監(jiān)聽(tīng)同一個(gè)端口的套接字只能位于同一個(gè)用戶下面。

? ? ? ? （4）、處理新建連接時(shí)，查找listener的時(shí)候，能夠支持在監(jiān)聽(tīng)相同IP和端口的多個(gè)sock之間均衡選擇。

當(dāng)一個(gè)連接到來(lái)的時(shí)候，系統(tǒng)到底是怎么決定那個(gè)套接字來(lái)處理它？

對(duì)于不同內(nèi)核，存在兩種模式，這兩種模式并不共存，一種叫做熱備份模式，另一種叫做負(fù)載均衡模式，3.9內(nèi)核以后，全部改為負(fù)載均衡模式。

熱備份模式：一般而言，會(huì)將所有的reuseport同一個(gè)IP地址/端口的套接字掛在一個(gè)鏈表上，取第一個(gè)即可，工作的只有一個(gè)，其他的作為備份存在，如果該套接字掛了，它會(huì)被從鏈表刪除，然后第二個(gè)便會(huì)成為第一個(gè)。
負(fù)載均衡模式：和熱備份模式一樣，所有reuseport同一個(gè)IP地址/端口的套接字會(huì)掛在一個(gè)鏈表上，你也可以認(rèn)為是一個(gè)數(shù)組，這樣會(huì)更加方便，當(dāng)有連接到來(lái)時(shí)，用數(shù)據(jù)包的源IP/源端口作為一個(gè)HASH函數(shù)的輸入，將結(jié)果對(duì)reuseport套接字?jǐn)?shù)量取模，得到一個(gè)索引，該索引指示的數(shù)組位置對(duì)應(yīng)的套接字便是工作套接字。這樣就可以達(dá)到負(fù)載均衡的目的，從而降低某個(gè)服務(wù)的壓力。

編程關(guān)于SO_REUSEPORT的詳細(xì)介紹請(qǐng)參考： SO_REUSEPORT?

參考資料：https://pureage.info/2015/12/22/thundering-herd.htmlhttp://www.tuicool.com/articles/2aumqehttp://blog.163.com/leyni@126/blog/static/16223010220122611523786/http://baike.baidu.com/link?url=6x0zTazmBxTYE9ngPt_boKjS8ivdQnRlfhHj-STCnqG9tjKwfCluPsKlq-ASUkdQTPW3XrD8FtyilBaI75GJCKhttp://m.blog.csdn.net/tuantuanls/article/details/41205739tcp對(duì)so_reuseport的優(yōu)化?

總結(jié)

以上是生活随笔為你收集整理的Linux惊群效应详解（最详细的了吧）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。