假設(shè)你經(jīng)營一家餐廳，服務(wù)員需要同時照顧100桌客人。如果每桌客人點菜都要服務(wù)員一直守候，餐廳早就倒閉了。而高并發(fā)服務(wù)器的設(shè)計同樣面臨類似問題——如何用最少的資源（線程）處理最多的請求（連接）？IO多路復(fù)用技術(shù)（select/poll/epoll） 就是解決這一難題的核心方案。

1.傳統(tǒng)阻塞模型的致命缺陷：資源浪費

想象一下，每個客戶進餐廳都必須配一個專屬服務(wù)員（線程）。當同時涌入1000名顧客時，餐廳需要雇傭1000名服務(wù)員，不僅人力成本爆炸，服務(wù)員之間還可能因協(xié)調(diào)混亂而撞車。這就是傳統(tǒng)阻塞IO模型的問題。

• 線程爆炸：每個連接獨占線程，1萬連接需1萬線程；
• 資源浪費：線程切換消耗CPU，內(nèi)存占用飆升；
• 性能瓶頸：線程數(shù)超過CPU核數(shù)后，響應(yīng)速度斷崖式下跌。

2.IO多路復(fù)用的核心思想：一個服務(wù)員看全場

IO多路復(fù)用就像給餐廳裝上智能呼叫鈴系統(tǒng)，服務(wù)員只需關(guān)注“亮燈”的桌子。其本質(zhì)是讓單線程監(jiān)控多個連接的就緒狀態(tài)，僅處理有數(shù)據(jù)到達的請求。實現(xiàn)這一目標的關(guān)鍵在于三種技術(shù)。

3.技術(shù)演進：從輪詢到事件驅(qū)動

select模型：全員點名式管理

工作原理

服務(wù)員手持一張座位表（fd_set），每次輪詢所有桌子（fd），挨個問“有菜要上嗎？”。

數(shù)據(jù)結(jié)構(gòu)

• fd_set是1024位的位圖，每位代表一個文件描述符（如fd=3對應(yīng)第3位）；
• 通過宏操作設(shè)置狀態(tài)：FD_SET(fd, &set)將對應(yīng)位置1，F(xiàn)D_CLR置0。

代碼示例

fd_set read_fds;
FD_ZERO(&read_fds);    // 清空座位表
FD_SET(sockfd, &read_fds); 
select(max_fd+1, &read_fds, NULL, NULL, NULL); // 開始輪詢

致命缺陷

• 座位表最多1024桌（可調(diào)整但性能下降）；
• 每次輪詢需全表拷貝到內(nèi)核（內(nèi)存開銷大）；
• 時間復(fù)雜度O(n)，萬級連接下CPU占用率飆升。

poll模型：升級版輪詢

改進點

• 用動態(tài)數(shù)組（pollfd結(jié)構(gòu)體）替代固定位圖，突破1024限制；
• 支持同時監(jiān)聽讀、寫、異常事件。

代碼示例

struct pollfd fds[1000];
fds[0].fd = sockfd; 
fds[0].events = POLLIN; // 監(jiān)聽讀事件
poll(fds, 1000, 500);  // 等待500ms

未解決問題

• 仍需全量遍歷所有fd（性能未質(zhì)變）；
• 數(shù)據(jù)拷貝開銷依然存在。

epoll模型：事件驅(qū)動的終極形態(tài)

設(shè)計哲學(xué)給每桌裝上智能呼叫鈴（回調(diào)機制），服務(wù)員只需關(guān)注鈴響的桌子。

核心組件

• 紅黑樹：存儲所有監(jiān)聽fd，插入/刪除時間復(fù)雜度O(log n)；
• 就緒隊列：僅存放已觸發(fā)事件的fd（直接處理無需遍歷）；
• 回調(diào)函數(shù)：數(shù)據(jù)到達時自動觸發(fā)，將fd加入就緒隊列。

觸發(fā)模式

• LT模式（默認）：鈴響后不關(guān)鈴，直到菜品取走（數(shù)據(jù)讀完）；
• ET模式：僅鈴響一次，需一次取完所有菜品（適合高性能場景）。

代碼流程

int epfd = epoll_create1(0); // 創(chuàng)建epoll實例
struct epoll_event ev;
ev.events = EPOLLIN | EPOLLET; // 邊緣觸發(fā)模式
ev.data.fd = sockfd;
epoll_ctl(epfd, EPOLL_CTL_ADD, sockfd, &ev); // 注冊到紅黑樹
while(1) {
  struct epoll_event events[100];
  int n = epoll_wait(epfd, events, 100, -1); // 等待事件
  for(int i=0; i<n; i++) {
    handle_event(events[i].data.fd); // 處理就緒fd
  }
}

性能優(yōu)勢：

• 時間復(fù)雜度O(1)，百萬連接下仍能快速響應(yīng)；
• 零拷貝技術(shù)：通過mmap共享內(nèi)存，避免數(shù)據(jù)來回拷貝。

4.橫向?qū)Ρ龋盒阅苤笖?shù)級躍遷

5.為何Redis、Nginx都選epoll？

Redis單線程扛10萬QPS

• 基于epoll的事件循環(huán)，單線程處理所有客戶端請求；
• 內(nèi)存操作+IO多路復(fù)用，避免線程切換開銷。

Nginx反向代理百萬連接

• 每個worker進程獨立epoll實例，均衡負載；
• ET模式確保高吞吐，避免LT模式下的重復(fù)通知。

在線游戲服務(wù)器

• 使用ET模式處理玩家指令，確保毫秒級響應(yīng)；
• 就緒隊列直接傳遞活躍玩家ID，避免遍歷全用戶列表。
• 
  

6.小結(jié)

• 傳統(tǒng)場景：連接數(shù)<1000，select/poll足矣（跨平臺兼容）；
• 高并發(fā)場景：Linux首選epoll，F(xiàn)reeBSD用kqueue，Windows用IOCP；
• 邊緣觸發(fā)陷阱：ET模式必須一次性讀完數(shù)據(jù)，否則會丟失事件。

未來趨勢：異步IO（如io_uring）正在崛起，但epoll在Linux中的地位十年內(nèi)仍難撼動。理解多路復(fù)用，不僅是面試考點，更是構(gòu)建高性能服務(wù)的基石。