NGINX 之所以能支撐高併發場景，其事件驅動模型是核心基石。該模型基於IO 多路複用技術，通過統一管理多個網絡連接的 IO 事件，避免傳統多進程模型的資源浪費。其中，select、kqueue、epoll 作為不同操作系統的 IO 多路複用實現，在 NGINX 中被靈活適配，共同構成高效的事件調度體系。
一、三種 IO 多路複用技術的底層實現差異
1. select：跨平台的基礎實現
select 是最早的 IO 多路複用接口，支持 Linux、Windows 等多平台。其底層通過位圖數組存儲文件描述符（FD），最多支持 1024 個 FD 監控。當調用 select 函數時，內核會遍歷所有註冊的 FD，檢查是否有 IO 事件就緒 —— 這種 “輪詢” 機制在 FD 數量增多時，會導致 CPU 使用率急劇上升，成為性能瓶頸。此外，select 每次調用後需重新註冊 FD 集合，進一步增加開銷。
2. epoll：Linux 下的性能標杆
epoll 是 Linux 2.6 + 推出的優化方案，完美解決 select 的缺陷。其底層通過紅黑樹存儲已註冊的 FD，支持無限量 FD 監控（僅受系統資源限制）；同時維護一個就緒事件鏈表，無需輪詢即可快速獲取就緒 FD。epoll 提供 EPOLLIN（讀事件）、EPOLLOUT（寫事件）等事件類型，通過epoll_ctl動態添加 / 刪除 FD，避免重複註冊。NGINX 在 Linux 環境下默認使用 epoll，正是看中其 “事件通知” 機制帶來的低延遲、高吞吐量特性。
3. kqueue：BSD 系統的高效選擇
kqueue 是 FreeBSD、macOS 等 BSD 類系統的 IO 多路複用實現，原理與 epoll 類似，但底層採用隊列結構管理事件。它不僅支持網絡 IO 事件，還能監控文件修改、信號等事件，功能更豐富。kqueue 通過kevent函數批量處理事件，支持邊緣觸發（ET）和水平觸發（LT）兩種模式，與 epoll 的觸發機制兼容，確保 NGINX 在 BSD 系統下仍能保持高效調度。
二、NGINX 的事件調度邏輯
NGINX 啓動時，會根據操作系統類型自動選擇 epoll、kqueue 或 select 作為事件驅動模塊。在 Master-Worker 架構中，每個 Worker 進程獨立維護一個事件驅動實例，避免進程間競爭。其調度流程可概括為三步：
- 事件註冊：Worker 進程接收新連接後，通過ngx_register_event將 FD 及對應的事件（如讀請求）註冊到事件驅動模塊；
- 事件等待：調用ngx_process_events（封裝了 epoll_wait/kqueue 等系統調用），阻塞等待就緒事件；
- 事件處理：當有 IO 事件就緒時，事件驅動模塊將就緒 FD 傳入 NGINX 的事件處理函數（如ngx_http_request_handler），處理完請求後重新註冊事件，進入下一輪循環。
三、關鍵觸發模式的選擇
NGINX 默認採用邊緣觸發（ET） 模式（僅 epoll 和 kqueue 支持）。在 ET 模式下，內核僅在 FD 狀態由 “未就緒” 變為 “就緒” 時通知一次，需一次性讀取 / 寫入所有數據，避免重複通知；而水平觸發（LT）會持續通知，直到數據處理完成。ET 模式雖需開發者更精細地處理數據讀寫，但能減少內核與用户態的切換次數，進一步提升 NGINX 的併發處理能力。
綜上，NGINX 通過適配不同操作系統的 IO 多路複用技術，構建了跨平台、高性能的事件驅動模型。其中 epoll 憑藉 “紅黑樹 + 就緒鏈表” 的底層設計，成為 Linux 環境下的最優解，而 kqueue 和 select 則確保了 NGINX 的跨平台兼容性 —— 這種靈活的技術選型，正是 NGINX 在高併發場景中屹立不倒的關鍵。
