1. 多路IO復(fù)用到底解決了什么問題聊到Linux系統(tǒng)編程很多同學(xué)一開始接觸的是阻塞式IO調(diào)用read等數(shù)據(jù)沒數(shù)據(jù)就掛在那兒直到內(nèi)核把數(shù)據(jù)準(zhǔn)備好。這種模型寫起來簡單但一遇到要同時處理幾十個、幾百個連接的服務(wù)端場景立刻就崩了——你沒法為每個連接開一個線程去阻塞等待線程開銷、上下文切換、內(nèi)存占用會直接把進(jìn)程拖垮。多路IO復(fù)用就是在這種背景下必須掌握的核心技術(shù)它讓單個進(jìn)程或線程同時監(jiān)視多個文件描述符內(nèi)核幫你盯著這堆描述符一旦某個或某幾個變得“可讀”或“可寫”內(nèi)核就通知你你再針對就緒的描述符做實(shí)際讀寫。這樣一來一個線程就能扛住成千上萬的并發(fā)連接典型的應(yīng)用就是Nginx、Redis單線程Reactor模型還有各種網(wǎng)絡(luò)代理和即時通訊服務(wù)端。先列出整套方案的三兄弟也是本篇文章的主角select最早出現(xiàn)的多路復(fù)用接口兼容性極好但內(nèi)核有FD_SETSIZE上限通常是1024且每次調(diào)用都要把整個fd集合從用戶態(tài)拷到內(nèi)核態(tài)效率不算高。poll本質(zhì)上是select的改進(jìn)版取消了1024的上限改用pollfd數(shù)組管理fd但依然有“全量拷貝 線性掃描”的問題fd數(shù)量多了同樣吃力。epollLinux特有的高性能方案紅黑樹加就緒鏈表的設(shè)計(jì)只把活躍的fd反饋給用戶連接數(shù)到十萬級別也不會明顯劣化是目前Linux服務(wù)端的絕對主力。如果你做的是跨平臺項(xiàng)目可能要評估一下select或poll的移植成本但只要你的運(yùn)行環(huán)境確定是Linux生產(chǎn)環(huán)境直接選epoll基本不會有爭議。后面我會依次拆解它們的工作原理、適用場景和實(shí)戰(zhàn)編碼最后再給出一些坑位提醒。2. 先摸透三兄弟的家底select、poll、epoll細(xì)節(jié)對比2.1 select老當(dāng)益壯但不適合大并發(fā)select接口長這樣#include sys/select.h #include sys/time.h int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);參數(shù)看著多其實(shí)是三組fd集合加一個超時時間。使用上的常規(guī)套路是fd_set read_fds; FD_ZERO(read_fds); FD_SET(sockfd, read_fds); int max_fd sockfd 1; int ret select(max_fd, read_fds, NULL, NULL, NULL); if (ret 0 FD_ISSET(sockfd, read_fds)) { // 這個連接有數(shù)據(jù)可讀 }第一次用select的人很容易栽在兩個細(xì)節(jié)上。第一個nfds并不是fd的數(shù)量而是“最大fd值加1”——就像你要給一堆排隊(duì)的人發(fā)號你至少要把號發(fā)到最大的那個號所以內(nèi)核是拿這個數(shù)字去遍歷0到nfds-1之間的所有fd而不是只看你注冊的這幾個。第二個select返回后fd_set里的內(nèi)容會被內(nèi)核改寫只保留就緒的fd所以下一輪循環(huán)必須重新FD_SET這個“重置”的操作如果漏掉輕則漏事件重則越界行為排查起來非常陰間。select真正讓人頭疼的瓶頸有三個單個進(jìn)程能監(jiān)視的fd數(shù)量受FD_SETSIZE限制默認(rèn)1024改內(nèi)核宏重新編譯才能擴(kuò)大但并不是所有系統(tǒng)都樂意支持。每次調(diào)用都要把fd_set從用戶態(tài)拷貝到內(nèi)核態(tài)fd多、調(diào)用頻繁時拷貝成本不可忽略。內(nèi)核不知道你關(guān)心哪些fd只能線性掃描全量fd掃描完還要把就緒結(jié)果拷回來。整個過程復(fù)雜度O(n)。所以我對select的定位是適合教學(xué)入門或者寫一些幾十個連接以內(nèi)的輕量工具。真到了生產(chǎn)級別的高并發(fā)它撐不住。2.2 poll取消了數(shù)量限制但復(fù)雜度沒變poll的接口看起來清爽不少#include poll.h struct pollfd { int fd; // 文件描述符 short events; // 關(guān)注的事件POLLIN、POLLOUT等 short revents; // 返回時內(nèi)核填充的就緒事件 }; int poll(struct pollfd *fds, nfds_t nfds, int timeout);用法上沒有select那一堆FD_SET宏了直接給一個數(shù)組填寫每個fd關(guān)注啥事件然后就等內(nèi)核通知。相比selectpoll有兩個明顯進(jìn)步突破了1024上限理論上fd數(shù)量只受系統(tǒng)最大文件數(shù)限制。pollfd結(jié)構(gòu)里把events和revents分開內(nèi)核填revents不會破壞你下次要用的events字段省掉了select那套“重新填充”的痛苦。但大家最不滿的一點(diǎn)沒變poll仍然需要把所有fd傳給內(nèi)核內(nèi)核仍然要逐個掃描所有fd檢查有沒有事件。換句話說時間復(fù)雜度還是O(n)當(dāng)連接數(shù)達(dá)到數(shù)萬級別每次poll都會變成一次小型災(zāi)難。如果說select是只能裝1000人的大巴那poll就是能把一萬人硬塞上車的大巴但上車的時候依然要一個個檢票。前者是容量不夠后者是檢票效率太拉胯。2.3 epollLinux下的大殺器epoll是Linux內(nèi)核專門針對海量連接場景設(shè)計(jì)的方案破局思路跟select/poll完全不同。先看核心接口#include sys/epoll.h // 創(chuàng)建epoll實(shí)例size參數(shù)從Linux 2.6.8之后被忽略但為了兼容還是給個大于0的值 int epoll_create(int size); // 增刪改fd及其關(guān)注事件 int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event); // 等待事件就緒就緒事件寫入events數(shù)組 int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);常規(guī)流程如下int epfd epoll_create(1024); struct epoll_event ev; ev.events EPOLLIN; // 關(guān)注可讀事件 ev.data.fd listen_fd; // 用data.fd記住這屬于哪個fd epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, ev); struct epoll_event events[1024]; while (1) { int n epoll_wait(epfd, events, 1024, -1); for (int i 0; i n; i) { // 處理 events[i].data.fd 上的事件 } }epoll的關(guān)鍵差異化設(shè)計(jì)在底層數(shù)據(jù)結(jié)構(gòu)。內(nèi)核維護(hù)一棵紅黑樹用來存你注冊的所有fd和對應(yīng)的事件。增刪改查都是O(log n)不用全量掃描。每個fd有事件就緒時內(nèi)核把它掛到一個就緒鏈表上。epoll_wait只需要把就緒鏈表的數(shù)據(jù)復(fù)制到用戶態(tài)然后清空鏈表。換句話說內(nèi)核通知你的是“已經(jīng)準(zhǔn)備好哪些”而不是“你去看看有哪些”。同時支持水平觸發(fā)LT和邊緣觸發(fā)ET兩種模式后面我專門展開講這個。所以當(dāng)連接數(shù)很大但活躍連接沒那么多時epoll的優(yōu)勢接近降維打擊——復(fù)雜度從O(n)變成O(就緒連接數(shù))。下表把三兄弟的關(guān)鍵差異集中對比一遍維度selectpollepoll最大fd數(shù)受FD_SETSIZE限制默認(rèn)1024無上限受系統(tǒng)限制無上限受系統(tǒng)限制用戶態(tài)到內(nèi)核態(tài)拷貝每次調(diào)用拷三組fd_set每次調(diào)用拷pollfd數(shù)組epoll_ctl注冊時拷貝epoll_wait只拷就緒事件內(nèi)核篩選方式線性掃描全部fd線性掃描全部fd紅黑樹管理注冊fd 就緒鏈表反饋時間復(fù)雜度O(n)O(n)O(就緒fd數(shù)量)水平觸發(fā)/邊緣觸發(fā)僅水平觸發(fā)僅水平觸發(fā)支持LT和ET跨平臺幾乎所有平臺Windows、Linux都可用僅Linux適合場景連接少、教學(xué)、輕量工具連接較多但活躍度不極端高并發(fā)、海量連接、高吞吐3. 實(shí)戰(zhàn)編碼從零寫一個基于epoll的TCP回顯服務(wù)器3.1 代碼整體結(jié)構(gòu)設(shè)計(jì)理論知識再多不落地就是空中樓閣。我習(xí)慣用一個簡潔的epoll回顯服務(wù)器來演示整套鏈路客戶端發(fā)什么服務(wù)端原樣返回什么。別小看這個Demo它涵蓋了服務(wù)端初始化、監(jiān)聽socket設(shè)置、epoll注冊、事件循環(huán)、accept新連接、讀寫業(yè)務(wù)處理的完整閉環(huán)是深入學(xué)習(xí)的基礎(chǔ)骨架。先搭框架#define MAX_EVENTS 1024 #define MAX_BUFFER_SIZE 4096 int main() { int listen_fd socket(AF_INET, SOCK_STREAM, 0); // 設(shè)置端口復(fù)用避免TIME_WAIT狀態(tài)導(dǎo)致重啟后bind失敗 int opt 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt)); struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_addr.s_addr htonl(INADDR_ANY); addr.sin_port htons(9000); bind(listen_fd, (struct sockaddr *)addr, sizeof(addr)); listen(listen_fd, 128); int epfd epoll_create(MAX_EVENTS); struct epoll_event ev; ev.events EPOLLIN; // 監(jiān)聽可讀 ev.data.fd listen_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, ev); // 事件循環(huán) struct epoll_event events[MAX_EVENTS]; while (1) { int nready epoll_wait(epfd, events, MAX_EVENTS, -1); for (int i 0; i nready; i) { int fd events[i].data.fd; if (fd listen_fd) { // 處理新連接 } else { // 處理既有連接上的數(shù)據(jù) } } } }這個結(jié)構(gòu)是所有事件驅(qū)動服務(wù)端的基本盤。每次epoll_wait返回后你要區(qū)分“這是新連接來了”還是“已有連接有數(shù)據(jù)”這里的if判斷就是事件分發(fā)器的雛形。3.2 新連接接入的處理細(xì)節(jié)當(dāng)listen_fd出現(xiàn)在就緒事件里說明有客戶端在握手。這里有一個非常關(guān)鍵的注意事項(xiàng)你得把新連接一次性全收下來而不是只accept一次。原因很簡單可能同時有多個客戶端連接完成如果只accept一個剩下的連接事件可能會在下一輪才再次通知但在高并發(fā)下這會增加延遲和瞬時壓力。標(biāo)準(zhǔn)做法是while循環(huán)accept直到返回EAGAIN為止if (fd listen_fd) { while (1) { int conn_fd accept(listen_fd, NULL, NULL); if (conn_fd -1) { if (errno EAGAIN || errno EWOULDBLOCK) { break; // 當(dāng)前沒有更多待處理的連接 } else { perror(accept error); break; } } // 把新連接加入epoll監(jiān)控 ev.events EPOLLIN | EPOLLET; // 邊緣觸發(fā)模式后面展開 ev.data.fd conn_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, conn_fd, ev); } }同時要給accept出來的conn_fd設(shè)置非阻塞屬性因?yàn)楹竺媾浜螮POLLET邊緣觸發(fā)時非阻塞是必要條件。設(shè)置方式int flags fcntl(conn_fd, F_GETFL, 0); fcntl(conn_fd, F_SETFL, flags | O_NONBLOCK);我給每個新連接設(shè)置的監(jiān)聽事件是EPOLLIN | EPOLLET用邊緣觸發(fā)。這個模式下內(nèi)核只在fd從“無事件”變成“有事件”的邊界通知一次不反復(fù)提醒所以讀數(shù)據(jù)時你必須一次性把緩沖區(qū)的數(shù)據(jù)全部讀完直到返回EAGAIN否則剩余數(shù)據(jù)可能要等下一次新事件才能再觸達(dá)——一旦有新事件覆蓋舊數(shù)據(jù)可能就被卡住了。3.3 連接數(shù)據(jù)的讀寫策略收到可讀事件后讀寫邏輯直接決定服務(wù)端的吞吐和穩(wěn)定性。我習(xí)慣用read配合固定緩沖區(qū)char buffer[MAX_BUFFER_SIZE]; while (1) { ssize_t n read(fd, buffer, sizeof(buffer)); if (n 0) { // 回顯給客戶端 write(fd, buffer, n); } else if (n 0) { // 讀到0說明對端關(guān)閉連接 close(fd); break; } else { if (errno EAGAIN || errno EWOULDBLOCK) { // 數(shù)據(jù)已經(jīng)讀完正常退出循環(huán) break; } else { // 真正出錯 close(fd); break; } } }這段代碼對ET模式來說是標(biāo)準(zhǔn)寫法一旦有讀事件就循環(huán)讀到EAGAIN。這里有個容易踩的坑寫端write不一定能一次寫完。比如客戶端接收窗口變小socket的發(fā)送緩沖滿了write可能返回EAGAIN。這時你可能要先把數(shù)據(jù)暫存到應(yīng)用層緩沖區(qū)等待EPOLLOUT事件再繼續(xù)發(fā)送。真正生產(chǎn)級的服務(wù)端一定是要處理寫緩沖區(qū)的這里為了講清楚多路復(fù)用的主線先不鋪開大復(fù)雜但你要有這個意識。3.4 用全套代碼串起來把上面幾段拼在一起補(bǔ)全頭部和細(xì)節(jié)就是一條非常完整的epoll服務(wù)端#include stdio.h #include stdlib.h #include string.h #include unistd.h #include fcntl.h #include errno.h #include sys/socket.h #include sys/epoll.h #include netinet/in.h #include arpa/inet.h #define MAX_EVENTS 1024 #define BUFFER_SIZE 4096 int set_nonblocking(int fd) { int flags fcntl(fd, F_GETFL, 0); if (flags -1) return -1; return fcntl(fd, F_SETFL, flags | O_NONBLOCK); } int main() { int listen_fd socket(AF_INET, SOCK_STREAM, 0); if (listen_fd -1) { perror(socket); exit(1); } int opt 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt)); set_nonblocking(listen_fd); struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_addr.s_addr htonl(INADDR_ANY); addr.sin_port htons(9000); if (bind(listen_fd, (struct sockaddr *)addr, sizeof(addr)) -1) { perror(bind); exit(1); } if (listen(listen_fd, 128) -1) { perror(listen); exit(1); } int epfd epoll_create(MAX_EVENTS); if (epfd -1) { perror(epoll_create); exit(1); } struct epoll_event ev; ev.events EPOLLIN; ev.data.fd listen_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, ev); struct epoll_event events[MAX_EVENTS]; while (1) { int nready epoll_wait(epfd, events, MAX_EVENTS, -1); for (int i 0; i nready; i) { int fd events[i].data.fd; if (fd listen_fd) { while (1) { int conn_fd accept(listen_fd, NULL, NULL); if (conn_fd -1) { if (errno EAGAIN || errno EWOULDBLOCK) break; perror(accept); break; } set_nonblocking(conn_fd); ev.events EPOLLIN | EPOLLET; ev.data.fd conn_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, conn_fd, ev); } } else { char buffer[BUFFER_SIZE]; int done 0; while (1) { ssize_t n read(fd, buffer, sizeof(buffer)); if (n 0) { write(fd, buffer, n); } else if (n 0) { done 1; break; } else { if (errno EAGAIN || errno EWOULDBLOCK) break; done 1; break; } } if (done) { epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL); close(fd); } } } } }這段代碼我已經(jīng)在自己機(jī)器上跑過很多次回顯功能是穩(wěn)定的。但它離生產(chǎn)級還差很遠(yuǎn)——沒有記錄每個連接的應(yīng)用層緩沖、沒有超時機(jī)制、沒有心跳檢測、沒有優(yōu)雅關(guān)閉流程。這些最終都需要在對多路復(fù)用充分理解后一層層補(bǔ)上去。4. 水平觸發(fā)與邊緣觸發(fā)的底層邏輯4.1 兩種模式的真實(shí)區(qū)別水平觸發(fā)LT是select和poll的內(nèi)置行為只要某個fd還有數(shù)據(jù)沒讀每次調(diào)用都會通知你。邊緣觸發(fā)ET則是內(nèi)核只在狀態(tài)變化的“邊緣”通知一次——比如數(shù)據(jù)從無到有那一刻提醒你之后即使你只讀了一半內(nèi)核也不會再提醒直到你把它讀完或者新數(shù)據(jù)再次到來。打一個生活化的比方水平觸發(fā)就像一個自動感應(yīng)水龍頭手沒拿開就一直出水邊緣觸發(fā)像老式門鈴你按一次響一次手一直按著不松開它也不會連續(xù)響。epoll默認(rèn)是LT模式這是很多資料沒強(qiáng)調(diào)的。如果你創(chuàng)建fd時只寫EPOLLIN那就是LT要啟用ET得寫成EPOLLIN | EPOLLET。LT的好處是編程簡單不用把數(shù)據(jù)一次性讀完不會丟數(shù)據(jù)壞處是內(nèi)核可能會多次通知同一個事件影響一點(diǎn)效率。ET的好處是通知次數(shù)少、處理及時性高適合高吞吐場景壞處是對編碼要求高——必須循環(huán)讀寫直到EAGAIN否則可能漏數(shù)據(jù)。4.2 怎么選LT還是ET我的建議分成三個檔位初學(xué)階段先用LT把epoll_wait、事件分發(fā)這些先跑通避免讀不干凈的坑干擾對主流程的理解。通常業(yè)務(wù)用LT也完全能支撐大量連接事實(shí)上很多主流服務(wù)在默認(rèn)配置下工作得很好不必盲目追求ET。極致性能場景例如網(wǎng)關(guān)、高吞吐代理用ET并配合非阻塞IO和循環(huán)讀寫能減少不必要的系統(tǒng)調(diào)用次數(shù)。還有一個非常實(shí)用的經(jīng)驗(yàn)用ET模式時你的fd必須是非阻塞的。因?yàn)镋T要求你會循環(huán)read到EAGAIN如果fd是阻塞的讀完數(shù)據(jù)后read會卡在那里整個進(jìn)程就卡死了。這個點(diǎn)面試常問實(shí)戰(zhàn)也常翻車務(wù)必記牢。5. 高并發(fā)避坑指南我踩過的那些坑5.1 坑1epoll_wait超時時間理解錯位很多人在epoll_wait的timeout傳-1意為永久阻塞。這是合理的但要注意如果所有fd都沒事件線程會一直睡在epoll_wait里如果服務(wù)端還有其他定時任務(wù)比如心跳檢測就需要epoll_wait定期超時返回一次好讓主循環(huán)有機(jī)會處理定時邏輯。更好的做法是把timeout設(shè)為定時任務(wù)的最小間隔例如100ms然后用當(dāng)前時間減上次處理時間來判斷哪些連接超時。強(qiáng)烈不建議用一個單獨(dú)的定時器線程去遍歷所有連接——如果連接數(shù)到了幾十萬每次全量遍歷本身就是巨大的損耗。5.2 坑2誤以為epoll_wait返回的events都是有效的epoll_wait返回的就緒事件里有的fd可能在你還沒來得及處理時就被對端關(guān)閉了。所以別假設(shè)每個事件對應(yīng)的fd一定可用讀寫之后要正確處理錯誤碼if (fd -1) continue; if (events[i].events (EPOLLERR | EPOLLHUP)) { // 對端異常斷開或掛斷做清理 close(fd); continue; }EPOLLERR和EPOLLHUP這兩個事件經(jīng)常被新手忽略但它們恰恰在一些異常場景下會先于EPOLLIN到達(dá)忽略的話fd就泄漏了。5.3 坑3fd泄漏每個accept出來的連接最終都要在close時成對出現(xiàn)。我見過寫服務(wù)端的人只在業(yè)務(wù)處理結(jié)束時close卻忘了從epoll里刪除fd。其實(shí)close(fd)會自動把fd從epoll中移除不用手動epoll_ctl(EPOLL_CTL_DEL)也可以但顯式刪除的好處是邏輯清晰可以防止某些怪異情況下的誤用。還有更隱蔽的泄漏accept失敗時沒處理、連接的收發(fā)緩沖沒清干凈就close、main循環(huán)異常退出但listen_fd沒關(guān)。建議在開發(fā)階段用lsof或/proc/PID/fd查看fd數(shù)量如果發(fā)現(xiàn)連接斷開后fd數(shù)不降趕緊查是不是漏了close。5.4 坑4邊緣觸發(fā)下循環(huán)讀卡死ET模式下如果對端持續(xù)發(fā)數(shù)據(jù)你一直循環(huán)讀一直有數(shù)據(jù)read就一直在返回這本來不是問題但如果你沒處理好EAGAIN循環(huán)會一直在那里空轉(zhuǎn)把CPU打滿。解決思路read到EAGAIN就break單個連接連續(xù)讀的總量加一個上限超過就先緩存把事件壓回隊(duì)列或者放到下次循環(huán)處理防止一個連接霸占CPU大批量數(shù)據(jù)下載場景適當(dāng)考慮用一個獨(dú)立的線程池做具體IO。6. 從單線程到多線程Reactor的演進(jìn)思路6.1 單線程Reactor模型上面演示的epoll事件循環(huán)就是典型的單線程Reactor模型一個線程負(fù)責(zé)epoll_wait、accept、讀寫。優(yōu)點(diǎn)簡單、無鎖、天然線程安全。 缺點(diǎn)一個連接的IO操作卡住整個服務(wù)端都阻塞。所以在這種模型下業(yè)務(wù)邏輯必須是非阻塞、快速返回的。適合場景Redis、部分代理、小型API網(wǎng)關(guān)。Redis之所以能單線程扛高吞吐核心就是所有命令內(nèi)存級響應(yīng)極快幾乎不阻塞。6.2 多線程Reactor模型的部署當(dāng)業(yè)務(wù)邏輯出現(xiàn)磁盤IO、數(shù)據(jù)庫交互、耗時計(jì)算等場景單線程Reactor扛不住就要演進(jìn)到多線程Reactor。主流做法是主線程只跑accept把新連接分發(fā)給多個子Reactor線程。每個子Reactor線程維護(hù)自己的epoll實(shí)例處理自己那批連接的讀寫和業(yè)務(wù)。這樣每個連接只會被一個線程長期占有減少了鎖競爭連接間的處理天然并行。如果你的業(yè)務(wù)里包含CPU密集計(jì)算甚至可以考慮再單獨(dú)拉線程池處理計(jì)算任務(wù)事件循環(huán)只負(fù)責(zé)收發(fā)數(shù)據(jù)數(shù)據(jù)到了就往計(jì)算線程池里丟算完結(jié)果再通過事件循環(huán)寫回。這是很多高性能服務(wù)器的通用架構(gòu)框架。6.3 事件驅(qū)動架構(gòu)的參考設(shè)計(jì)在設(shè)計(jì)高并發(fā)服務(wù)時我會把整個模塊拆成四個角色連接管理器維護(hù)所有連接的fd、讀寫緩沖區(qū)、超時時間和狀態(tài)。事件循環(huán)驅(qū)動epoll_wait執(zhí)行事件分發(fā)。處理器具體處理讀到的數(shù)據(jù)分發(fā)給業(yè)務(wù)模塊或線程池。發(fā)送隊(duì)列管理寫緩沖和EPOLLOUT事件避免寫阻塞。這套設(shè)計(jì)把多路復(fù)用從一個“能用”的接口變成一套“能擴(kuò)展”的架構(gòu)。你的服務(wù)能并發(fā)多少很大程度上取決于事件循環(huán)對每個連接的處理是否足夠輕量。7. 實(shí)測表現(xiàn)壓測數(shù)據(jù)帶來的直觀體感實(shí)踐出真知。我用同一臺虛擬機(jī)分別寫了基于select和基于epoll的回顯服務(wù)器用本機(jī)工具模擬并發(fā)連接。連接數(shù)在500以下時兩者延遲差別不大都在毫秒級。但當(dāng)連接數(shù)到5000select已經(jīng)明顯出現(xiàn)周期性延遲抖動CPU占用也偏高epoll依然平穩(wěn)p99延遲基本維持在個位數(shù)毫秒。一旦把連接數(shù)推到2萬以上select直接無法工作而epoll依然沒有成為瓶頸。這背后的道理其實(shí)很簡單select每次都要把2萬個fd全量掃描一遍而epoll只需要關(guān)注真正活躍的幾百個fd。也就是說活躍連接占比越低epoll的相對優(yōu)勢越大。極端情況下如果每個連接都在持續(xù)收發(fā)數(shù)據(jù)epoll的優(yōu)勢會被壓縮但依然不會出現(xiàn)全量掃描的問題。如果你需要做實(shí)測可以先寫一個客戶端循環(huán)建立連接并定時發(fā)送心跳服務(wù)端打印當(dāng)前連接數(shù)和epoll_wait的返回延遲?，F(xiàn)象會非常直觀。同時注意壓測時要監(jiān)控CPU、內(nèi)存、句柄數(shù)三個維度別只盯著延遲。8. 挑選多路復(fù)用方案時的一些個人建議8.1 明確你能接受的內(nèi)核依賴epoll是Linux專屬。如果你的服務(wù)要跑在macOS、Windows或者其他Unix變體上要么用跨平臺的libevent、libuv這類封裝庫要么自己包一層抽象接口。很多公司做中間件時選擇對上層屏蔽IO模型的細(xì)節(jié)底層在Linux用epoll在其他平臺退回kqueue或poll上層只看到統(tǒng)一的add、del、wait接口。這種設(shè)計(jì)雖然增加了工作量但跨平臺遷移時就舒服很多。8.2 連接模型選型的判斷公式以我個人經(jīng)驗(yàn)連接類型大致能分兩類低頻連接連接建立后大部分時間閑置偶爾發(fā)個心跳或小請求。這類適合用LT模式省心不丟事件。高頻流式數(shù)據(jù)比如視頻流、消息推送、日志采集。這類適合ET模式減少重復(fù)通知吞吐更高。服務(wù)端設(shè)計(jì)沒有銀彈但核心思路是一致的少拷貝、少遍歷、少阻塞、及時清理無效連接。理解了多路復(fù)用背后的原則換任何封裝的網(wǎng)絡(luò)庫都能很快上手。8.3 最后分享一個開發(fā)階段的實(shí)用技巧我在調(diào)試epoll服務(wù)時經(jīng)常會在epoll_wait返回后加一段臨時日志打印就緒fd數(shù)量和當(dāng)前總fd數(shù)。這個日志在聯(lián)調(diào)階段幫過大忙——有一次線上疑似連接泄漏我在一次版本里短暫加了這段日志定位到是一條錯誤路徑上accept成功后沒有注冊到epoll就提前返回后續(xù)數(shù)據(jù)永遠(yuǎn)沒事件客戶端干等連接也一直沒釋放。工具方面平時strace跟蹤系統(tǒng)調(diào)用、lsof查fd、ss或netstat看連接狀態(tài)都是調(diào)試網(wǎng)絡(luò)服務(wù)的得力幫手。這套技能棧補(bǔ)上之后系統(tǒng)編程的地基才算真正打穩(wěn)。