Nginx由核心和模組組成。

Nginx本身做的工作實際很少，當它接到一個HTTP請求時，它僅僅是通過查詢配置檔案將此次請求對映到一個location block，而此location中所配置的各個指令則會啟動不同的模組去完成工作，因此模組可以看做Nginx真正的勞動工作者。通常一個location中的指令會涉及一個handler模組和多個filter模組（當然，多個location可以複用同一個模組）。handler模組負責處理請求，完成響應內容的生成，而filter模組對響應內容進行處理。

使用者根據自己的需要開發的模組都屬於第三方模組。正是有了這麼多模組的支撐，Nginx的功能才會如此強大。

Nginx的模組從結構上分為核心模組、基礎模組和第三方模組：

核心模組：HTTP模組、EVENT模組和MAIL模組 基礎模組：HTTP Access模組、HTTP FastCGI模組、HTTP Proxy模組和HTTP Rewrite模組， 第三方模組：HTTP Upstream Request Hash模組、Notice模組和HTTP Access Key模組。

Nginx的模組從功能上分為如下三類：

Handlers（處理器模組）。此類模組直接處理請求，並進行輸出內容和修改headers資訊等操作。Handlers處理器模組一般只能有一個。 Filters （過濾器模組）。此類模組主要對其他處理器模組輸出的內容進行修改操作，最後由Nginx輸出。 Proxies （代理類模組）。此類模組是Nginx的HTTP Upstream之類的模組，這些模組主要與後端一些服務比如FastCGI等進行互動，實現服務代理和負載均衡等功能。

Nginx程序模型

　Nginx預設採用多程序工作方式，Nginx啟動後，會執行一個master程序和多個worker程序。其中master充當整個程序組與使用者的互動介面，同時對程序進行監護，管理worker程序來實現重啟服務、平滑升級、更換日誌檔案、配置檔案實時生效等功能。worker用來處理基本的網路事件，worker之間是平等的，他們共同競爭來處理來自客戶端的請求。

nginx的程序模型如圖所示：

在建立master程序時，先建立需要監聽的socket（listenfd），然後從master程序中fork()出多個worker程序，如此一來每個worker程序多可以監聽使用者請求的socket。一般來說，當一個連線進來後，所有在Worker都會收到通知，但是隻有一個程序可以接受這個連線請求，其它的都失敗，這是所謂的驚群現象。nginx提供了一個accept_mutex（互斥鎖），有了這把鎖之後，同一時刻，就只會有一個程序在accpet連線，這樣就不會有驚群問題了。

先開啟accept_mutex選項，只有獲得了accept_mutex的程序才會去新增accept事件。nginx使用一個叫ngx_accept_disabled的變數來控制是否去競爭accept_mutex鎖。ngx_accept_disabled = nginx單程序的所有連線總數 / 8 -空閒連線數量，當ngx_accept_disabled大於0時，不會去嘗試獲取accept_mutex鎖，ngx_accept_disable越大，於是讓出的機會就越多，這樣其它程序獲取鎖的機會也就越大。不去accept，每個worker程序的連線數就控制下來了，其它程序的連線池就會得到利用，這樣，nginx就控制了多程序間連線的平衡。

每個worker程序都有一個獨立的連線池，連線池的大小是worker_connections。這裡的連線池裡面儲存的其實不是真實的連線，它只是一個worker_connections大小的一個ngx_connection_t結構的陣列。並且，nginx會通過一個連結串列free_connections來儲存所有的空閒ngx_connection_t，每次獲取一個連線時，就從空閒連線連結串列中獲取一個，用完後，再放回空閒連線連結串列裡面。一個nginx能建立的最大連線數，應該是worker_connections * worker_processes。當然，這裡說的是最大連線數，對於HTTP請求本地資源來說，能夠支援的最大併發數量是worker_connections * worker_processes，而如果是HTTP作為反向代理來說，最大併發數量應該是worker_connections * worker_processes/2。因為作為反向代理伺服器，每個併發會建立與客戶端的連線和與後端服務的連線，會佔用兩個連線。

Nginx處理HTTP請求流程

　http請求是典型的請求-響應型別的的網路協議。http是檔案協議，所以我們在分析請求行與請求頭，以及輸出響應行與響應頭，往往是一行一行的進行處理。通常在一個連線建立好後，讀取一行資料，分析出請求行中包含的method、uri、http_version資訊。然後再一行一行處理請求頭，並根據請求method與請求頭的資訊來決定是否有請求體以及請求體的長度，然後再去讀取請求體。得到請求後，我們處理請求產生需要輸出的資料，然後再生成響應行，響應頭以及響應體。在將響應傳送給客戶端之後，一個完整的請求就處理完了。

處理流程圖：

相關推薦