一周至少一篇到今天已經(jīng)持續(xù)30周了，希望每一篇多多少少能給大家?guī)?lái)點(diǎn)干貨。同樣的，今天分享的基本上一面試就會(huì)被問(wèn)的網(wǎng)絡(luò)IO。文中涉及的代碼部分不太重要，重要的是對(duì)這概念的理解。在看文章之前大家也可通過(guò)下面的思維導(dǎo)圖看看自己是否能回答出來(lái)。

1 阻塞與非阻塞--開(kāi)胃菜

• 阻塞

我們知道在調(diào)用某個(gè)函數(shù)的時(shí)候無(wú)非就是兩種情況，要么馬上返回，然后根據(jù)返回值進(jìn)行接下來(lái)的業(yè)務(wù)處理。當(dāng)在使用阻塞IO的時(shí)候，應(yīng)用程序會(huì)被無(wú)情的掛起，等待內(nèi)核完成操作，因?yàn)榇藭r(shí)的內(nèi)核可能將CPU時(shí)間切換到了其他需要的進(jìn)程中，在我們的應(yīng)用程序看來(lái)感覺(jué)被卡主(阻塞)了。

傳統(tǒng)阻塞IO模型

特點(diǎn)：

• 通過(guò)阻塞式IO獲取輸入的數(shù)據(jù)

• 其中每個(gè)連接都采用獨(dú)立的線程完成數(shù)據(jù)輸入，業(yè)務(wù)處理以及數(shù)據(jù)返回的操作

這種方案有什么問(wèn)題？

首先當(dāng)并發(fā)較大的時(shí)候，需要?jiǎng)?chuàng)建大量的線程來(lái)處理連接，需要占用大量的系統(tǒng)資源。

連接建立完成以后，如果當(dāng)前線程沒(méi)有數(shù)據(jù)可讀，將會(huì)阻塞在read操作上造成線程資源的浪費(fèi)

鑒于上面的兩個(gè)問(wèn)題，通常是解決方案是啥呢？

第一種是采用IO復(fù)用的模型，所謂IO復(fù)用模型即多個(gè)連接共享一個(gè)阻塞對(duì)象，應(yīng)用程序只會(huì)在一個(gè)阻塞對(duì)象上等待。當(dāng)某個(gè)連接有新的數(shù)據(jù)處理，操作系統(tǒng)直接通知應(yīng)用程序，線程從阻塞狀態(tài)返回并開(kāi)始業(yè)務(wù)處理

第二種方案即采用線程池復(fù)用的方式。將連接完成后的業(yè)務(wù)處理任務(wù)分配給線程，一個(gè)線程處理多個(gè)連接的業(yè)務(wù)。IO復(fù)用結(jié)合線程池的方案即Reactor模式。

從上圖我們可以發(fā)現(xiàn)，通過(guò)一個(gè)或者多個(gè)請(qǐng)求傳遞給服務(wù)器，通過(guò)統(tǒng)一的事件管理機(jī)制進(jìn)行請(qǐng)求分發(fā)，這種模式即事件驅(qū)動(dòng)處理模式。

通常一個(gè)服務(wù)端處理網(wǎng)絡(luò)請(qǐng)求的過(guò)程是啥樣的？

服務(wù)端將這些請(qǐng)求分別同步分派給多個(gè)處理線程，即IO多路復(fù)用統(tǒng)一監(jiān)聽(tīng)事件，收到事件再進(jìn)行分發(fā)。那么圖中重要的兩個(gè)關(guān)鍵字是啥意思？

Reactor

在一個(gè)單獨(dú)的線程運(yùn)行，主要負(fù)責(zé)監(jiān)聽(tīng)和分發(fā)事件。就仿佛我們手機(jī)設(shè)置的轉(zhuǎn)接，將來(lái)自前任的電話轉(zhuǎn)接給適當(dāng)?shù)穆?lián)系人

Handlers

主要負(fù)責(zé)處理執(zhí)行IO實(shí)際的事情。

根據(jù)Reactor的數(shù)量和處理的資源大小通常又分為單Reactor線程，單Reactor多線程，主從Reactor多線程。這部分將在文章后面進(jìn)行詳細(xì)闡述，先和大家一起復(fù)習(xí)幾個(gè)基本概念

• 非阻塞

當(dāng)使用非阻塞函數(shù)的時(shí)候，和阻塞IO類(lèi)比，內(nèi)核會(huì)立即返回，返回后獲得足夠的CPU時(shí)間繼續(xù)做其他的事情。

這樣說(shuō)可能有點(diǎn)不太好理解，試試一個(gè)例子來(lái)

小藍(lán)經(jīng)常去樓下的小賣(mài)部買(mǎi)煙，因?yàn)槟切〗憬愦_實(shí)好看，即使不買(mǎi)去看看也飽了那種。有一天去買(mǎi)煙，讓我等下，他去倉(cāng)庫(kù)看看，就一直在那里等著小姐姐回復(fù)，就仿佛阻塞在了小姐姐的店。

那么阻塞IO是個(gè)啥樣子嘞？

小姐姐，今天有黃鶴樓煙沒(méi)，小姐姐看看了柜臺(tái)，沒(méi)有，到處找也沒(méi)有了，然后告訴我這周沒(méi)有了，下周應(yīng)該會(huì)有貨，好嘛，我寂寞的小手顫抖了，其實(shí)我就是想去小姐姐家買(mǎi)東西，于是下周我又去問(wèn)小姐姐，小姐姐果然有心，就知道我回去她家店買(mǎi)，直接給我留了兩包黃鶴樓，就這樣反反復(fù)復(fù)，和小姐姐的感情越來(lái)越好，這樣就是阻塞IO的輪詢，我沒(méi)有被阻塞而是不斷地咨詢小姐姐(輪詢)。

抽煙的人，經(jīng)常一句話就是“這一根抽了就不抽了”，怎么能忍住一周？看來(lái)輪詢效率太低，直接給小姐姐打電話：“小姐姐，煙到了麻煩通知一聲，我來(lái)你家拿”，這就是IO多路復(fù)用。

感情嘛，最激烈的時(shí)期不外乎是最開(kāi)始的那么兩個(gè)月，不，渣男，怎么可能就兩個(gè)月，感情真是越來(lái)越好，然后我就給小姐姐說(shuō)：“小姐姐，我給你個(gè)地址，還有微信，到時(shí)候到貨了麻煩給我寄過(guò)來(lái)”，這尼瑪，不僅加了微信，還給我送到了家，這就是異步IO，至于后續(xù)的故事是怎么樣的想知道？

好勒，就是寫(xiě)IO模型，配上線程/進(jìn)程所向披靡(網(wǎng)絡(luò)編程的核心)

非阻塞IO之讀(繼續(xù)查閱資料)

咱們知道套接字有個(gè)緩沖區(qū)，如果緩沖區(qū)沒(méi)有數(shù)據(jù)可讀，那么在非阻塞的情況下調(diào)用read就會(huì)立即返回，返回自然會(huì)有個(gè)狀態(tài)，不然我們一臉懵逼，無(wú)法進(jìn)行下一步。返回可能是EWOULDBLOCK或者EAGAIN出錯(cuò)信息。

非阻塞IO之寫(xiě)

剛才我們說(shuō)了，有個(gè)叫做緩沖區(qū)的概念，當(dāng)然也有發(fā)送緩沖區(qū)，如果發(fā)送緩沖區(qū)滿了，不能容納更多的字節(jié)，這個(gè)時(shí)候操作系統(tǒng)內(nèi)核就會(huì)盡全力從應(yīng)用程序拷貝數(shù)據(jù)到發(fā)送緩沖區(qū)并立即從write調(diào)用返回。在拷貝的過(guò)程中，可能全部拷貝了，也可能一字節(jié)也沒(méi)拷貝，所以使用返回值來(lái)告訴應(yīng)用程序到底有多少數(shù)據(jù)拷貝到了發(fā)送發(fā)送緩沖區(qū)，方便再次調(diào)用write，輸出未完成的字節(jié)。

總結(jié)下兩種方式:

阻塞IO是：拷貝-知道所有數(shù)據(jù)拷貝到發(fā)送緩沖區(qū)。

非阻塞IO是拷貝-返回-再拷貝-再返回。ok，read和write的騷操作如下圖

說(shuō)了這么多，當(dāng)面試官問(wèn)你的時(shí)候，能不能對(duì)答如流嘞，總結(jié)如下：

• read總是在接受緩存區(qū)有數(shù)據(jù)的時(shí)候直接返回，而不是等到應(yīng)用程序哥頂?shù)臄?shù)據(jù)充滿才返回。如果此時(shí)緩沖區(qū)是空的，那么阻塞模式會(huì)等待，非阻塞則會(huì)返回-1并有EWOULDBLOCK或EAGAIN錯(cuò)誤

• 和read不太一樣的是，在阻塞模式下，write只有在發(fā)送緩沖區(qū)足矣容納應(yīng)用程序的輸出字節(jié)時(shí)才會(huì)返回。在非阻塞的模式下，能寫(xiě)入多少則寫(xiě)入多少，并返回實(shí)際寫(xiě)入的字節(jié)數(shù) ? ? ?

當(dāng)使用fgets等待標(biāo)準(zhǔn)輸入的時(shí)候，如果此時(shí)套接字有數(shù)據(jù)但不能讀出。IO多路復(fù)用意味著可以將標(biāo)準(zhǔn)輸入、套接字等都當(dāng)做IO的一路，任何一路IO有事件發(fā)生，都將通知相應(yīng)的應(yīng)用程序去處理相應(yīng)的IO事件，在我們看來(lái)就反復(fù)同時(shí)可以處理多個(gè)事情。這就是IO復(fù)用。

2 select

當(dāng)使用select函數(shù)的時(shí)候，先通知內(nèi)核掛起進(jìn)程，一旦一個(gè)或者多個(gè)IO事情發(fā)生，控制權(quán)將返回給應(yīng)用程序，然后由應(yīng)用程序進(jìn)行IO處理。

那么IO事件都包含哪些

• 標(biāo)準(zhǔn)輸入文件描述符可以讀

• 已連接套接字準(zhǔn)備好可以寫(xiě)

• 如果一個(gè)IO事件等待超過(guò)10秒，發(fā)生超時(shí)

select使用方法

int?select(int?maxfdp,?fd_set?*readset,?fd_set?*writeset,?fd_set?*exceptset,struct?timeval?*timeout);

• maxfdp 表示待測(cè)試描述符基數(shù)，它的值為待測(cè)試最大描述符加1.假設(shè)當(dāng)前的select的測(cè)試描述符集合為{0,1,3}，那么這個(gè)時(shí)候maxfd為4，

• 隨后為三個(gè)描述符集合，分別為讀集合readset，寫(xiě)集合writeset和異常集合exceptset。它們會(huì)通知內(nèi)核，當(dāng)有可讀可寫(xiě)發(fā)生的時(shí)候記得通知它們

如何設(shè)置這些描述符

int?FD_ZERO(int?fd,?fd_set?*fdset);???//一個(gè)?fd_set類(lèi)型變量的所有位都設(shè)為?0
int?FD_CLR(int?fd,?fd_set?*fdset);??//清除某個(gè)位時(shí)可以使用
int?FD_SET(int?fd,?fd_set?*fd_set);???//設(shè)置變量的某個(gè)位置位
int?FD_ISSET(int?fd,?fd_set?*fdset);?//測(cè)試某個(gè)位是否被置位

最后一個(gè)參數(shù)是時(shí)間

struct?timeval
{??????
????long?tv_sec;???/*秒?*/
????long?tv_usec;??/*微秒?*/???
};

• 設(shè)置為NULL，select會(huì)一直等待下去

• 設(shè)置非零值，等待固定時(shí)間后返回

• 將tv_sec和tv_usec均設(shè)置為0，表示不等待，檢測(cè)完畢就返回

程序案例

#include?
#include?
#include?
#include?
#include?
#include?

const?static?int?MAXLINE?=?1024;
const?static?int?SERV_PORT?=?10001;

int?main()
{
????int?i?,?maxi?,?maxfd,?listenfd?,?connfd?,?sockfd?;
????/*nready?描述字的數(shù)量*/
????int?nready?,client[FD_SETSIZE];
????int?n?;
????/*創(chuàng)建描述字集合，由于select函數(shù)會(huì)把未有事件發(fā)生的描述字清零，所以我們?cè)O(shè)置兩個(gè)集合*/
????fd_set?rset?,?allset;
????char?buf[MAXLINE];
????socklen_t?clilen;
????struct?sockaddr_in?cliaddr?,?servaddr;
????/*創(chuàng)建socket*/
????listenfd?=?socket(AF_INET?,?SOCK_STREAM?,?0);
????/*定義sockaddr_in*/
????memset(&servaddr?,?0?,sizeof(servaddr));
????servaddr.sin_family?=?AF_INET;
????servaddr.sin_port?=?htons(SERV_PORT);
????servaddr.sin_addr.s_addr?=?htonl(INADDR_ANY);

????bind(listenfd,?(struct?sockaddr?*)?&?servaddr?,?sizeof(servaddr));
????listen(listenfd?,?100);
????/*listenfd?是第一個(gè)描述字*/
????/*最大的描述字，用于select函數(shù)的第一個(gè)參數(shù)*/
????maxfd?=?listenfd;
????/*client的數(shù)量，用于輪詢*/
????maxi?=?-1;
????/*init*/
????for(i=0?;i????????client[i]?=?-1;
????FD_ZERO(&allset);
????FD_SET(listenfd,?&allset);

????for?(;;)
????{
????????rset?=?allset;
????????/*只select出用于讀的描述字，阻塞無(wú)timeout*/
????????nready?=?select(maxfd+1?,?&rset?,?NULL?,?NULL?,?NULL);
????????if(FD_ISSET(listenfd,&rset))
????????{
????????????clilen?=?sizeof(cliaddr);
????????????connfd?=?accept(listenfd?,?(struct?sockaddr?*)?&?cliaddr?,?&clilen);
????????????/*尋找第一個(gè)能放置新的描述字的位置*/
????????????for?(i=0;i????????????{
????????????????if(client[i]<0)
????????????????{
????????????????????client[i]?=?connfd;
????????????????????break;
????????????????}
????????????}
????????????/*找不到，說(shuō)明client已經(jīng)滿了*/
????????????if(i==FD_SETSIZE)
????????????{
????????????????printf("Too?many?clients?,?over?stack?.\n");
????????????????return?-1;
????????????}
????????????FD_SET(connfd,&allset);//設(shè)置fd
????????????/*更新相關(guān)參數(shù)*/
????????????if(connfd?>?maxfd)?maxfd?=?connfd;
????????????if(i>maxi)?maxi?=?i;
????????????if(nready<=1)?continue;
????????????else?nready?--;
????????}

????????for(i=0?;?i<=maxi?;?i++)
????????{
????????????if?(client[i]<0)?continue;
????????????sockfd?=?client[i];
????????????if(FD_ISSET(sockfd,&rset))
????????????{
????????????????n?=?read(sockfd?,?buf?,?MAXLINE);
????????????????if?(n==0)
????????????????{
????????????????????/*當(dāng)對(duì)方關(guān)閉的時(shí)候，server關(guān)閉描述字，并將set的sockfd清空*/
????????????????????close(sockfd);
????????????????????FD_CLR(sockfd,&allset);
????????????????????client[i]?=?-1;
????????????????}
????????????????else
????????????????{
????????????????????buf[n]='\0';
????????????????????printf("Socket?%d?said?:?%s\n",sockfd,buf);
????????????????????write(sockfd,buf,n);?//Write?back?to?client
????????????????}
????????????????nready?--;
????????????????if(nready<=0)?break;
????????????}
????????}

????}
????return?0;
}

但是他有個(gè)比較明顯的特點(diǎn)就是所支持文件描述符有限，默認(rèn)為1024個(gè)，隨機(jī)出現(xiàn)poll

3 poll

鑒于select所支持的描述符有限，隨后提出poll解決這個(gè)問(wèn)題

還是先看聲明

int?poll(struct?pollfd?*fds,?nfds_t?nfds,?int?timeout);

再看pollfd結(jié)構(gòu)

struct?pollfd?{
????int???fd;?????????/*?文件描述符?*/
????short?events;?????/*?描述符待檢測(cè)的事件?*/
????short?revents;????/*?returned?events?*/
};

注意下這個(gè)結(jié)構(gòu)體，分別包含了文件描述符和描述符對(duì)應(yīng)的事件，這事件和文件描述符緊密相結(jié)合，其中事件使用二進(jìn)制掩碼表示，如POLLIN代表讀事件，POLLOUT代表寫(xiě)事件。

#define?POLLIN?0x0001?/*?any?readable?data?available?*/
#define?POLLPRI?0x0002?/*?OOB/Urgent?readable?data?*/
#define?POLLOUT?0x0004?/*?file?descriptor?is?writeable?*/

從結(jié)構(gòu)中可以看見(jiàn)還有個(gè)參數(shù)是revents，從字面意思可知事件備份。對(duì)的，相當(dāng)于將poll每次檢測(cè)的結(jié)果保留在revents，這樣就不需要每次都重置描述符和事件。那到底有哪些事件

• 可讀事件---系統(tǒng)內(nèi)核會(huì)通知應(yīng)用程序數(shù)據(jù)可讀

#define?POLLIN?0x0001?/*?any?readable?data?available?*/
#define?POLLPRI?0x0002?/*?OOB/Urgent?readable?data?*/
#define?POLLRDNORM?0x0040?/*?non-OOB/URG?data?available?*/
#define?POLLRDBAND?0x0080?/*?OOB/Urgent?readable?data?*/

• 可寫(xiě)事件---系統(tǒng)內(nèi)核會(huì)通知套接字緩沖區(qū)已經(jīng)可以安排，隨后使用write函數(shù)不會(huì)被堵塞

#define?POLLOUT?0x0004?/*?file?descriptor?is?writeable?*/
#define?POLLWRNORM?POLLOUT?/*?no?write?type?differentiation?*/
#define?POLLWRBAND?0x0100?/*?OOB/Urgent?data?can?be?written?*/

了解函數(shù)返回值

• 小于0----表示事件發(fā)生前永遠(yuǎn)等待

• -1---發(fā)生錯(cuò)誤

• 0--在指定的而時(shí)間沒(méi)有任何事件發(fā)生

poll和select不同之處在于，在select中，文件描述符個(gè)數(shù)隨著fd_set的實(shí)現(xiàn)而固定，而在poll函數(shù)中，我們可以通過(guò)控制pollfd數(shù)組的大小來(lái)改變描述符的個(gè)數(shù)

案例

#include?
#include?
#include?
#include?
#include?
#include?

#define?INFTIM?-1
#define?POLLRDNORM??0x040???????/*?Normal?data?may?be?read.??*/
#define?POLLRDBAND??0x080???????/*?Priority?data?may?be?read.??*/
#define?POLLWRNORM??0x100???????/*?Writing?now?will?not?block.??*/
#define?POLLWRBAND??0x200???????/*?Priority?data?may?be?written.??*/

#define?MAXLINE??1024
#define?OPEN_MAX??16?//一些系統(tǒng)會(huì)定義這些宏
#define?SERV_PORT??10001

int?main()
{
????int?i?,?maxi?,listenfd?,?connfd?,?sockfd?;
????int?nready;
????int?n;
????char?buf[MAXLINE];
????socklen_t?clilen;
????struct?pollfd?client[OPEN_MAX];

????struct?sockaddr_in?cliaddr?,?servaddr;
????listenfd?=?socket(AF_INET?,?SOCK_STREAM?,?0);
????memset(&servaddr,0,sizeof(servaddr));
????servaddr.sin_family?=?AF_INET;
????servaddr.sin_port?=?htons(SERV_PORT);
????servaddr.sin_addr.s_addr?=?htonl(INADDR_ANY);

????bind(listenfd?,?(struct?sockaddr?*)?&?servaddr,?sizeof(servaddr));
????listen(listenfd,10);
????client[0].fd?=?listenfd;
????client[0].events?=?POLLRDNORM;
????for(i=1;i????{
????????client[i].fd?=?-1;
????}
????maxi?=?0;

????for(;;)
????{
????????nready?=?poll(client,maxi+1,INFTIM);
????????if?(client[0].revents?&?POLLRDNORM)
????????{
????????????clilen?=?sizeof(cliaddr);
????????????connfd?=?accept(listenfd?,?(struct?sockaddr?*)&cliaddr,?&clilen);
????????????for(i=1;i????????????{
????????????????if(client[i].fd<0)
????????????????{
????????????????????client[i].fd?=?connfd;
????????????????????client[i].events?=?POLLRDNORM;
????????????????????break;
????????????????}
????????????}
????????????if(i==OPEN_MAX)
????????????{
????????????????printf("too?many?clients!?\n");
????????????}
????????????if(i>maxi)?maxi?=?i;
????????????nready--;
????????????if(nready<=0)?continue;
????????}

????????for(i=1;i<=maxi;i++)
????????{
????????????if(client[i].fd<0)?continue;
????????????sockfd?=?client[i].fd;
????????????if(client[i].revents?&?(POLLRDNORM|POLLERR))
????????????{
????????????????n?=?read(client[i].fd,buf,MAXLINE);
????????????????if(n<=0)
????????????????{
????????????????????close(client[i].fd);
????????????????????client[i].fd?=?-1;
????????????????}
????????????????else
????????????????{
????????????????????buf[n]='\0';
????????????????????printf("Socket?%d?said?:?%s\n",sockfd,buf);
????????????????????write(sockfd,buf,n);?//Write?back?to?client
????????????????}
????????????????nready--;
????????????????if(nready<=0)?break;?//no?more?readable?descriptors
????????????}
????????}
????}
????return?0;
}

5 epoll

epoll 通過(guò)監(jiān)控注冊(cè)的多個(gè)描述字，來(lái)進(jìn)行 I/O 事件的分發(fā)處理。不同于 poll 的是，epoll 不僅提供了默認(rèn)的 level-triggered（條件觸發(fā)）機(jī)制，還提供了性能更為強(qiáng)勁的edge triggered（邊緣觸發(fā)）機(jī)制

在The Linux Programming Interface有張圖展示三種IO復(fù)用技術(shù)在面對(duì)不同文件描述符時(shí)的差異

從上圖咱們知道即使10000個(gè)描述符的時(shí)候，常規(guī)的select和poll性能下降明顯，而epoll變化不大

那么epoll是什么操作這么6？

epoll通過(guò)監(jiān)控注冊(cè)多個(gè)描述字進(jìn)行IO事件的分發(fā)。不同poll的是，epoll不僅提供默認(rèn)的level-trigger機(jī)制還提供了邊緣觸發(fā)機(jī)制，這里可以先思考下兩者有什么區(qū)別

編程三步驟

int?epoll_create(int?size);

就是通過(guò)它來(lái)創(chuàng)造實(shí)例，這個(gè)返回的值將用于后續(xù)的技能解鎖，如果不需要了這個(gè)實(shí)例，則需要使用close方法來(lái)釋放示例，不要占著坑不拉屎，這樣很不道德。

那這個(gè)size是干撒子的嘞？它告訴內(nèi)核期望監(jiān)控多少個(gè)描述符，然后使用這部分的信息來(lái)初始化內(nèi)核底層的數(shù)據(jù)結(jié)構(gòu)，不過(guò)時(shí)代在變化，在現(xiàn)在高版本的實(shí)現(xiàn)中，不在需要這個(gè)參數(shù)，自動(dòng)動(dòng)態(tài)化了，高級(jí)了吧。

int?epoll_ctl(int?epfd,?int?op,?int?fd,?struct?epoll_event?*event);

創(chuàng)建了實(shí)例，并有了返回值來(lái)標(biāo)識(shí)這個(gè)示例，是時(shí)候添加事件了，此時(shí)就是使用epoll_ctl。第一個(gè)參數(shù)epfd即是上面的返回值。第二個(gè)參數(shù)表示是準(zhǔn)備刪除事件還是監(jiān)控事件，哪都有哪些選項(xiàng)呢

第三個(gè)參數(shù)為注冊(cè)事件的文件描述符比如一個(gè)監(jiān)聽(tīng)字

第四個(gè)參數(shù)表示注冊(cè)的事件類(lèi)型，可以在這個(gè)結(jié)構(gòu)體中自定義數(shù)據(jù)。

int?epoll_wait(int?epfd,?struct?epoll_event?*events,?int?maxevents,?int?timeout);
//返回值:?成功返回的是一個(gè)大于?0?的數(shù)，表示事件的個(gè)數(shù)；返回?0?表示的是超時(shí)時(shí)間到；若出錯(cuò)返回?-1

epoll_wait函數(shù)和之前的select等類(lèi)似，等待內(nèi)核IO事件的分發(fā)。第一個(gè)參數(shù)為create返回值句柄。第二個(gè)參數(shù)回給用戶空間需要處理的 I/O 事件。第三個(gè)參數(shù)為一個(gè)大于0的整數(shù)，表示epoll_wait可以返回的最大事件值。第四個(gè)參數(shù)是epoll_wait阻塞時(shí)的超時(shí)值，如果設(shè)置為-1表示不超時(shí)，如果設(shè)置為0則立即返回。

6 epoll的底層實(shí)現(xiàn)

這部分內(nèi)容，我在之前的文章中提過(guò)且給大家分享過(guò)一篇源碼筆記，大家需要的話也可以微信找我拿。

• 當(dāng)我們使用epoll_fd增加一個(gè)fd的時(shí)候，內(nèi)核會(huì)為我們創(chuàng)建一個(gè)epitem實(shí)例，講這個(gè)實(shí)例作為紅黑樹(shù)的節(jié)點(diǎn)，此時(shí)你就可以BB一些紅黑樹(shù)的性質(zhì)，當(dāng)然你如果遇到讓你手撕紅黑樹(shù)的大哥，在最后的提問(wèn)環(huán)節(jié)就讓他寫(xiě)寫(xiě)吧

• 隨后查找的每一個(gè)fd是否有事件發(fā)生就是通過(guò)紅黑樹(shù)的epitem來(lái)操作

• epoll維護(hù)一個(gè)鏈表來(lái)記錄就緒事件，內(nèi)核會(huì)當(dāng)每個(gè)文件有事件發(fā)生的時(shí)候?qū)⒆约旱怯浀竭@個(gè)就緒列表，然后通過(guò)內(nèi)核自身的文件file-eventpoll之間的回調(diào)和喚醒機(jī)制，減少對(duì)內(nèi)核描述字的遍歷，大俗事件通知和檢測(cè)的效率

7 C10K問(wèn)題

這里的C代表并發(fā)，10K=10000。雖然現(xiàn)在通過(guò)現(xiàn)成的框架libevent/Netty可以輕松完成這個(gè)目標(biāo)，但是在二十多年前，突破這個(gè)并發(fā)量還是非常困難的。那么要同時(shí)支撐這么多用戶，需要從哪些方面考慮呢

• 文件句柄

我們知道每個(gè)連接代表一個(gè)文件描述符，如果不夠用，新的鏈接將會(huì)被丟棄并產(chǎn)生錯(cuò)誤

在Linux中默認(rèn)為1024，但是如果你是root，你可以通過(guò)/etc/sysctl.cong來(lái)修改，使得支持1w個(gè)描述符

• 系統(tǒng)內(nèi)存

每個(gè)連接不是只占用鏈接套接字那么簡(jiǎn)單，每個(gè)鏈接都需要占用發(fā)送緩沖區(qū)和接收緩沖區(qū)，不信我們看看

上面三個(gè)值分別代表的是最小分配值、默認(rèn)分配至和最大分配至，這樣如果1w個(gè)連接需要消耗

此時(shí)假設(shè)一個(gè)連接需要128K緩沖區(qū)，那么 1w 個(gè)連接大約需要 1.2G 應(yīng)用層緩沖，所以支持w的連接不是內(nèi)存的問(wèn)題。

• 網(wǎng)絡(luò)帶寬

假設(shè)當(dāng)前10個(gè)連接，其中每個(gè)鏈接傳輸大約1KB的數(shù)據(jù)，那么帶寬需要10 * 10000 * 1KB/s * 8=80MBPS。在現(xiàn)在看來(lái)也是很一般了

那么如何解決C10K問(wèn)題？

• 一方面需要考慮到IO，也就是上面說(shuō)的阻塞IO和非阻塞IO

• 如何分配進(jìn)程，線程的資源服務(wù)上w的連接

阻塞IO與進(jìn)程

這個(gè)好理解，來(lái)個(gè)連接我就分配個(gè)進(jìn)程(fork)去處理，這個(gè)進(jìn)程處理此鏈接的所有IO，不管是阻塞還是非阻塞IO，多個(gè)連接也不會(huì)產(chǎn)生影響，畢竟進(jìn)程之間有著各自的進(jìn)程空間

進(jìn)程是程序執(zhí)行的最小單位，一個(gè)進(jìn)程有著完整的地址空間，程序計(jì)數(shù)器，想要?jiǎng)?chuàng)建一個(gè)進(jìn)程，使用fork即可，fork后會(huì)在父子進(jìn)程中各返回一次，如果返回值為0則是子進(jìn)程，隨后父子進(jìn)程處理各自的邏輯

創(chuàng)建完進(jìn)程執(zhí)行了任務(wù)，當(dāng)要離開(kāi)的時(shí)候需要清理干凈資源，如果退出了還將進(jìn)程的相關(guān)信息留下，不回收就會(huì)變?yōu)?strong style="font-size: inherit;line-height: inherit;color: rgb(255, 69, 0);">僵尸進(jìn)程。這些僵尸進(jìn)程不是沒(méi)人管了，會(huì)交給一個(gè)叫做 init 的進(jìn)程，如果僵尸進(jìn)程太多，勢(shì)必會(huì)占用太多的內(nèi)存空間甚至耗盡我們的系統(tǒng)資源。

那如果想主動(dòng)的回收這些資源，怎么辦呢？

處理子進(jìn)程退出一般是注冊(cè)一個(gè)信號(hào)處理函數(shù)，然后捕捉信號(hào)SIGCHILD信號(hào)，在信號(hào)處理函數(shù)中調(diào)用waitpid函數(shù)完成資源的回收即可。

假設(shè)此時(shí)服務(wù)端開(kāi)始監(jiān)聽(tīng)，兩個(gè)客戶端AB分別連接服務(wù)端，客戶端A發(fā)起請(qǐng)求后，連接成立返回新的套接字叫做連接套接字，此時(shí)父進(jìn)程派生子進(jìn)程，在子進(jìn)程中使用連接套接字和客戶端通信，所以這個(gè)時(shí)候子進(jìn)程不關(guān)心監(jiān)聽(tīng)套接字。父進(jìn)程則相反，服務(wù)交給子進(jìn)程后，不再關(guān)心連接套接字，而是關(guān)心監(jiān)聽(tīng)套接字，如下圖所示

缺點(diǎn)：效率不高，擴(kuò)展性較差且資源占用率高

此時(shí)客戶端B發(fā)來(lái)新的請(qǐng)求，accept返回新的已連接套接字，父進(jìn)程又派生子進(jìn)程

部分實(shí)現(xiàn)

while?(1)
????{
????????if?((conn?=?accept(listenfd,?(struct?sockaddr?*)&peeraddr,?&peerlen))?0)?//3次握手完成的序列
????????????ERR_EXIT("accept?error");
????????printf("recv?connect?ip=%s?port=%d\n",?inet_ntoa(peeraddr.sin_addr),
???????????????ntohs(peeraddr.sin_port));

????????pid?=?fork();
????????if?(pid?==?-1)
????????????ERR_EXIT("fork?error");
????????if?(pid?==?0)
????????{
????????????//?子進(jìn)程
????????????close(listenfd);
????????????do_service(conn);
????????????exit(EXIT_SUCCESS);
????????}
????????else
????????????close(conn);?//父進(jìn)程
????}

缺點(diǎn)：效率不高，擴(kuò)展性較差且資源占用率高，注意事項(xiàng)

• 對(duì)套接字的關(guān)閉

• 子進(jìn)程的回收

阻塞IO+線程

剛才不是說(shuō)進(jìn)程占用資源多么，那么就是用線程唄。單進(jìn)程中可以有多個(gè)線程，每個(gè)線程都有自己的上下文，包括唯一標(biāo)識(shí)的線程ID 程序計(jì)數(shù)器等，同一個(gè)進(jìn)程的多個(gè)線程共享整個(gè)虛擬地址空間，其中包含了代碼、數(shù)據(jù)、堆。

為什么線程的上下文的開(kāi)銷(xiāo)比進(jìn)程少呢

我們的代碼是交給CPU執(zhí)行的，程序計(jì)數(shù)器會(huì)告訴CPU代碼執(zhí)行到哪兒了，寄存器呢會(huì)存儲(chǔ)當(dāng)前計(jì)算的中間值，內(nèi)存存放當(dāng)前使用的變量，當(dāng)切換到另外的計(jì)算場(chǎng)景的時(shí)候，需要重新載入新的值，這個(gè)時(shí)候就出現(xiàn)了上下文的切換

現(xiàn)在每個(gè)連接由一個(gè)線程處理

do{
????accept?connections
????pthread_create?for?conneced?connection?fd
????thread_run(fd)
}while(true)

主線程負(fù)責(zé)監(jiān)聽(tīng)連接請(qǐng)求

while?(1)
????{
????//服務(wù)一直在運(yùn)行，直到被某個(gè)操作或命令終止該進(jìn)程
????int?recvbytes;
????socklen_t?length?=?sizeof(cliaddr);

????//accept()函數(shù)讓服務(wù)器接收客戶的連接請(qǐng)求
????int?clientfd?=?accept(servfd,(struct?sockaddr*)&cliaddr,&length);

????if?(clientfd?0)
????{
????????printf("error?comes?when?call?accept!\n");
????????break;
????}

????//?創(chuàng)建用于處理新連接的子線程
????pthread_t?recv_id?;
????pthread_create(&recv_id,?NULL,?recv_msg_from_client,?&clientfd);
????}

每個(gè)客戶連接的線程函數(shù)

void*?recv_msg_from_client(void*?arg)
{
????//?分離線程，使主線程不必等待此線程
????pthread_detach(pthread_self());

????int?clientfd?=?*(int*)arg;

????int?recvBytes?=?0;
????char*?recvBuf?=?new?char[BUFFER_SIZE];
????memset(recvBuf,?0,?BUFFER_SIZE);

????while(1)
????{
????????if?((recvBytes=recv(clientfd,?recvBuf,?BUFFER_SIZE,0))?<=?0)?
????????{
????????????perror("recv出錯(cuò)！\n");
????????????return?NULL;
????????}
????????recvBuf[recvBytes]='\0';
????????printf("recvBuf:%s\n",?recvBuf);
????}

????close(clientfd);
????return?NULL;
}

可是頻繁的創(chuàng)建線程也還是比較耗資源，這樣子是不是可以使用線程池提前創(chuàng)建一波線程，多個(gè)連接復(fù)用它即可

上面程序雖然可以較好地處理連接，但是如果并發(fā)較多，就會(huì)引起線程的頻繁切換和銷(xiāo)毀，怎們優(yōu)化？

我們?cè)诜?wù)端啟動(dòng)的時(shí)候，預(yù)先分配固定大小的多個(gè)線程，當(dāng)新連接建立的時(shí)候，從連接隊(duì)列中取出這個(gè)連接描述字進(jìn)程處理

細(xì)心地同學(xué)可能發(fā)現(xiàn)，既要從隊(duì)列取數(shù)據(jù)，也會(huì)從隊(duì)列寫(xiě)數(shù)據(jù)，會(huì)不會(huì)有混亂。是的，所以通常還會(huì)使用mutex和條件變量進(jìn)行加持。

但是不是每個(gè)鏈接都是需要時(shí)刻服務(wù)，每次創(chuàng)建線程還是比較消耗資源，那就提前創(chuàng)建一批線程，所謂線程池，復(fù)用線程池來(lái)獲取某種效率的提升

非阻塞 I/O + readiness notification + 單線程

我們的程序可以通過(guò)輪詢的方式對(duì)套接字進(jìn)行挨個(gè)訪問(wèn)，從而找出進(jìn)行IO處理的套接字。

描述符少還行，如果太多，每次的循環(huán)將消耗大量的CPU時(shí)間，而且可能循環(huán)完了都沒(méi)發(fā)現(xiàn)一個(gè)套接字可以讀寫(xiě)。既然這樣，我們直接交給操作系統(tǒng)，讓它告訴我們哪些套接字可以讀寫(xiě)。程序就變?yōu)檫@樣

我們每次dispatch就相當(dāng)于對(duì)所有的套接字進(jìn)行排查，這樣顯然效率不是很高。如果dispatch之后只提供有IO事件或者IO變化的套接字就好了，這就是epoll的設(shè)計(jì)

非阻塞 I/O + readiness notification + 多線程

上述幾種方案都是在一個(gè)線程分發(fā)，顯然沒(méi)有利用當(dāng)今的多核技術(shù)，我們完全可以讓每個(gè)核作為一個(gè)IO分發(fā)器進(jìn)行事件的分發(fā)，這其實(shí)就是reactor模式，也是后續(xù)將談到的事件驅(qū)動(dòng)。

8 事件驅(qū)動(dòng)

事件驅(qū)動(dòng)也叫做反應(yīng)堆模型或者Event loop模型，重要的是兩點(diǎn)

• 通過(guò)poll、epoll等IO分發(fā)技術(shù)實(shí)現(xiàn)一個(gè)無(wú)限循環(huán)的事件分發(fā)線程

• 將所有的IO事件抽象為事件，每個(gè)事件設(shè)置回調(diào)函數(shù)

在處理大部分網(wǎng)絡(luò)程序的時(shí)候，無(wú)外乎處理一下幾個(gè)事兒

• 從套接字讀取數(shù)據(jù) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

• 對(duì)收到的數(shù)據(jù)進(jìn)行解析

• 根據(jù)解析的內(nèi)容進(jìn)行計(jì)算處理

• 處理后的結(jié)果按照約定的格式編碼

• 通過(guò)套接字發(fā)送出去

那么之前我們說(shuō)了使用fork子進(jìn)程的方式實(shí)現(xiàn)通信，隨著客戶端的增多，處理效率不高，因?yàn)閒ork的開(kāi)銷(xiāo)太大

為什么說(shuō)事件驅(qū)動(dòng)是一種高性能，高并發(fā)的模式？

既然這么牛皮，當(dāng)然有它的特點(diǎn)。舉個(gè)例子，來(lái)成都一個(gè)月，印象特別深刻卻是到處都是咖啡館，點(diǎn)一杯咖啡坐著一邊喝一邊看妹子，服務(wù)員小姐姐也不會(huì)找我，只有當(dāng)我去續(xù)杯的時(shí)候，再找小姐姐勾搭(觸發(fā)事件了)，小姐姐滿足了我的需求，我就接著邊喝咖啡邊看其他小姐姐，這就是事件驅(qū)動(dòng)?？磦€(gè)圖

為了模式整體的效率，不能因?yàn)樘幚順I(yè)務(wù)邏輯導(dǎo)致IO事件處理的效率下降，所以我們決定將注入XML文件的解析，數(shù)據(jù)庫(kù)的查找等工作放在其他線程中，所謂將這些工作和反應(yīng)堆線程解耦。讓這個(gè)反應(yīng)堆只處理IO相關(guān)任務(wù)，業(yè)務(wù)邏輯這些操作分成小任務(wù)放在線程池中讓其他空閑的線程處理。處理完后再交給反應(yīng)堆，然后發(fā)送出去

主從Reactor

ok，咱們已經(jīng)知道使用Reactor反應(yīng)堆的方式同時(shí)分發(fā)Acceptor上的連接建立事件，但是我們還是沒(méi)有完全實(shí)現(xiàn)解耦，這個(gè)Reactor線程既要分發(fā)連接建立，還要分發(fā)已經(jīng)建立連接的IO，如果太多的客戶請(qǐng)求是不是會(huì)處理不過(guò)來(lái)，那么能不能讓其分離嘞

我們看看主從reactor的方式，思路很清晰，主reactor主負(fù)責(zé)分發(fā)Acceptor連接建立，然后已經(jīng)聯(lián)機(jī)的IO事件交給sub-reactor，這個(gè)sub-reactor的數(shù)量可以根據(jù)CPU的核數(shù)來(lái)定。

假設(shè)咱們是一個(gè)四核的CPU，設(shè)置sub-reactor為4.這個(gè)時(shí)候4個(gè)反應(yīng)堆同時(shí)干活，是不是增強(qiáng)了IO分發(fā)處理的效率，因?yàn)槎嗪瞬僮?，也大大的減少并發(fā)處理的鎖開(kāi)銷(xiāo)。

epoll

上面說(shuō)了poll的reactor反應(yīng)堆模式，和poll相比，epoll可謂更加高效的事件機(jī)制。

如何切換到epoll呢

在lib/event_loop.c中的event_loop_init_with_name中，可以發(fā)現(xiàn)通過(guò)宏EPOLL_ENABEL來(lái)決定使用哪一個(gè)

然后我們?cè)诟夸浿胁榭碈MakeLists.txt文件，如果系統(tǒng)中有epoll_create就會(huì)自動(dòng)開(kāi)啟EPOLL_ENALE，如果沒(méi)有則采用默認(rèn)的poll作為事件分發(fā)機(jī)制。

這還沒(méi)完，我們需要讓編譯器知道這個(gè)宏，所以需要讓CMake往config.h文件寫(xiě)入這個(gè)宏的最終值。

那么，為啥epoll的性能就比poll更好呢

• 首先poll和select，在使用之前需要一個(gè)感興趣的事件集合，系統(tǒng)內(nèi)核通過(guò)它構(gòu)建相應(yīng)的數(shù)據(jù)結(jié)構(gòu)并注冊(cè)，epoll卻不是，它會(huì)維護(hù)一個(gè)全局的事件集合，通過(guò)epoll的句柄操作這個(gè)集合，操作系統(tǒng)內(nèi)核不需要每次重新掃描整個(gè)集合

• 使用poll或者select的時(shí)候，應(yīng)用程序需要掃描整個(gè)感興趣的事件集合并找出活動(dòng)的事件，如果請(qǐng)求量過(guò)大，掃描一次花費(fèi)的時(shí)間就太長(zhǎng)。而epoll不是，epoll直接返回活動(dòng)的事件，減少大量的掃描時(shí)間。

那么邊緣觸發(fā)與條件觸發(fā)到底是啥意思

• 如果某個(gè)套接字有1000個(gè)字節(jié)需要讀，兩個(gè)方案都會(huì)產(chǎn)生read ready notification，如果應(yīng)用程序只讀了500字節(jié)，就會(huì)陷入等待，對(duì)于條件觸發(fā)就不一樣，它會(huì)因?yàn)檫€有500字節(jié)而不斷地產(chǎn)生read ready notification

異步IO

用程序告知內(nèi)核啟動(dòng)某個(gè)操作，并讓內(nèi)核在整個(gè)操作（包括將數(shù)據(jù)從內(nèi)核拷貝到應(yīng)用程序的緩沖區(qū)）完成后通知應(yīng)用程序。那么和信號(hào)驅(qū)動(dòng)有啥不一樣?

信號(hào)驅(qū)動(dòng)IO試內(nèi)核通知應(yīng)用程序什么時(shí)候啟動(dòng)一個(gè)IO操作。而異步IO模型是由內(nèi)核通知應(yīng)用程序啥時(shí)候完成。

異步IO的主要優(yōu)點(diǎn)是充分的利用DMA特性。缺點(diǎn)是，如果要完成真正的異步IO，對(duì)于操作系統(tǒng)的壓力較大，需要做大量的工作。

現(xiàn)在我們已經(jīng)知道了阻塞IO 非阻塞IO，以及通過(guò)select epoll poll等IO多路復(fù)用并結(jié)合線程池的方案實(shí)現(xiàn)高性能的網(wǎng)絡(luò)框架。但是還有個(gè)與之相對(duì)應(yīng)叫做proactor的網(wǎng)絡(luò)驅(qū)動(dòng)模式，兩者有什么區(qū)別？

在windows中這一套完整的支持套接字的異步編程接口叫做IOCP，和Reactor模式一樣之處在于，也存在一個(gè)無(wú)限循環(huán)的event loop線程的，但是不同于Reactor模式，這個(gè)線程不負(fù)責(zé)處理IO調(diào)用，只是負(fù)責(zé)在對(duì)應(yīng)的read，write操作完成的情況下，分發(fā)完成事件道不同的處理函數(shù)。簡(jiǎn)單的一句話總結(jié)即Reactor模式基于待完成的IO事件，而Proactor模式基于已完成的IO事件。

嘮嗑

謝謝大家的查看，如果有點(diǎn)幫助，不凡給小弟在下方點(diǎn)個(gè)贊和在看，這對(duì)我非常重要，另外，因?yàn)檫@樣，你也可以第一時(shí)間收到干貨的推送啦。see you…