NGINX 架構 - 《事件驅動架構》

韋弘智

發佈於〈NGINX〉影子書

2022/06/30閱讀時間約 3 分鐘

上一篇有講完【NGINX 架構 - 《模組化設計》】後，接下來這邊透過自己的理解，來專門介紹『事件趨動架構』，以此來幫助自己認識NGINX架構的內容。

什麼是「事件驅動架構」

事件驅動架構並非是NGINX獨有的名詞，也並非只應用於電腦程式設計領域，它是一種古老的回應事件模型，在電腦程式設計、公共關係、經濟活動等領域均有很廣泛的應用。《節錄於 Nginx技術手札：網頁伺服器應用全攻略 3.3章節》

而這邊指的事件驅動架構是一種程式設計的方式 - 事件驅動程式設計（Event-driven programming）

事件驅動程式設計（Event-driven programming）是一種電腦程式設計模型。這種模型的程式執行流程是由使用者的動作（如滑鼠的按鍵，鍵盤的按鍵動作）或者是由其他程式的訊息來決定的。更多細節，可閱維基百科《事件驅動程式設計》

事件驅動架構，主要是由「事件收集器」、「事件發送器」、「事件處理器」三個基本單元組成的，如同名稱上的意思，由使用者觸發事件(滑鼠點擊)，然後透過事件收集器來收集事件，再由事件發送器來分配事件，最後才由事件處理器來處理這些事件。

事件驅動架構

Nginx Server回應和處理Web請求的過程，就是以事件驅動模型為基礎的，因此事件收集器和事件發送器，顧名思義，就不需要多做解釋了，最主要的是「事件處理器」。

事件收集器：負責收集 worker 進程的各種 IO 請求
事件發送器：負責將 IO 事件發送到事件處理器
事件處理器：負責各種事件的響應工作

事件處理器有三種實現的方式：

1. 進程(Process)事件處理器

「事件處理器」收到事件後，「目標物件」就建立一個進程(Process)，來處理該事件，透過此方式處理事件，會讓Server負擔較大，因此效能較差，但實現較為容易。

進程的優缺點：
優點：每個進程有自己獨立的系統資源分配空間，不同進程之間的資源不共享，因此不需要特別對進程做互斥存取的處理。
缺點：建立進程以及進程的上下文切換（Context Switch）都較消耗資源，進程間若有通訊的需求也較為複雜。
(截錄於：莫力全 Kyle Mo - 程序(進程)、執行緒(線程)、協程，傻傻分得清楚！ )

2. 線程(thread)事件處理器

「事件處理器」收到事件後，「目標物件」就建立一個線程(thread)，來處理該事件，透過此方式處理事件，可能會遇到鎖死、同步等諸多問題，且編碼複雜。

3. 非阻塞I/O事件處理器

「事件處理器」收到事件後，「目標物件」就將其放入一個待處理事件的列表，使用非阻塞I/O方式來處理事件。透過此方式處理事件，代碼、邏輯都比上述兩者還複雜，現今大多數網路伺服器都是採用此種方式，因此就有了「事件驅動處理函數庫」。

使用多線程或多進程來處理，會有以下兩種缺點 :
1. 高併發會爆，因此進程或線程數有限制，且上下文切換。
2. 如果應用大部份的服務是 I/O 會很浪費資源(因為就為了等待，而用不少記憶體開進程，但是他大部份都只是在等待)。
(截錄於拿鐵派的馬克 Blog - 30-07 之應用層的 I/O 優化 - 非阻塞 I/O 模型)