事件驅動
事件驅動（Event Driven）是一種核心的編程範式，其根本特徵是控制反轉（Inversion of Control，IoC）。在這種模型中，程序的執行流不再由代碼的順序調用決定，而是由一系列異步發生的事件來驅動。應用程序的角色從主動輪詢或等待，轉變為被動地對事件做出響應，這構成了現代高性能系統的基礎。
一個完整的事件驅動架構由四個基本部分組成，它們協同工作，構成了高效的事件處理流程。
1）事件源（Event Source）：事件的產生者。在網絡編程中，最典型的事件源就是操作系統內核，它負責監視網絡連接、文件句柄等資源的狀態變化。
2）事件（Event）：對狀態變化的封裝。例如，一個數據包到達網卡，內核會生成一個“讀就緒”事件；一個TCP連接請求被接受，會生成一個“連接就緒”事件。每個事件都包含了足夠的信息（如關聯的文件描述符）以供後續處理。
3）事件循環（Event Loop）：整個範式的引擎。它是一個持續運行的循環，其唯一職責就是向事件源查詢是否有新事件發生。一旦獲取到事件，它並不會自己處理，而是將事件分發給預先註冊的處理器。基於epoll的while (true) { epoll_wait(...); }結構就是最經典的事件循環實現。
4）事件處理器（Event Handler）：預先定義的、用於處理特定事件的邏輯代碼。這通常是一個函數或一個對象的方法。當事件循環將事件分發過來時，相應的處理器被調用，執行具體的業務邏輯，如讀取數據、發送響應或關閉連接。

為什麼需要Reactor模型
C10K問題（即同時處理1萬個併發連接）是客户端-服務器模型在高併發場景下的典型挑戰，由Dan Kegel於1999年提出。傳統多線程模型在處理大規模併發連接時面臨嚴重瓶頸：每一個連接創建一個線程（Thread-per-Connection）會導致內存消耗過高、上下文切換開銷過大以及文件描述符資源耗盡。此外，阻塞I/O操作會使線程在等待數據時閒置，降低處理器利用率。
一種優化策略是使用線程池：服務器啓動時創建固定數量的線程，組成線程池。當新連接到達時，從線程池分配空閒線程處理連接，處理完成後線程返回池中等待下一個任務。然而，由於使用阻塞I/O，當併發連接數過大時，線程池中的線程可能全部處於等待I/O操作的狀態，導致處理器資源浪費。

為解決這些問題，Reactor模型應運而生。Reactor模型是事件驅動思想在網絡I/O領域最經典的實現，它利用操作系統的I/O多路複用機制（如Linux的epoll），使少數線程甚至單個線程能夠同時處理大量客户端連接。此外，它還支持輕鬆修改或擴展請求處理邏輯，儘管存在編程複雜度較高和調試難度較大的侷限性。
在Reactor模式中，服務器不再為每個連接創建線程，而是將所有連接的文件描述符統一註冊到一箇中央事件循環中。這個事件循環通過epoll_wait等調用，以極低的成本同時監視海量連接。只有當某個連接上真正有事件發生時（如數據到達），操作系統才會喚醒事件循環，後者再將事件精確地分發給對應的處理器去執行非阻塞的讀寫操作。處理完畢後，控制權立刻返回事件循環，繼續等待下一批事件。

未完待續

很高興與你相遇！如果你喜歡本文內容，記得關注哦