Nginx工作原理

Nginx由內(nèi)核和模塊組成。

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

用戶根據(jù)自己的需要開發(fā)的模塊都屬于第三方模塊。正是有了這么多模塊的支撐，Nginx的功能才會如此強大。

Nginx的模塊從結(jié)構(gòu)上分為核心模塊、基礎(chǔ)模塊和第三方模塊：

• 核心模塊：HTTP模塊、EVENT模塊和MAIL模塊
• 基礎(chǔ)模塊：HTTP Access模塊、HTTP FastCGI模塊、HTTP Proxy模塊和HTTP Rewrite模塊，
• 第三方模塊：HTTP Upstream Request Hash模塊、Notice模塊和HTTP Access Key模塊。
  

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

• Handlers（處理器模塊）。此類模塊直接處理請求，并進行輸出內(nèi)容和修改headers信息等操作。Handlers處理器模塊一般只能有一個。
• Filters （過濾器模塊）。此類模塊主要對其他處理器模塊輸出的內(nèi)容進行修改操作，最后由Nginx輸出。
• Proxies （代理類模塊）。此類模塊是Nginx的HTTP Upstream之類的模塊，這些模塊主要與后端一些服務比如FastCGI等進行交互，實現(xiàn)服務代理和負載均衡等功能。

Nginx進程模型

　　Nginx默認采用多進程工作方式，Nginx啟動后，會運行一個master進程和多個worker進程。其中master充當整個進程組與用戶的交互接口，同時對進程進行監(jiān)護，管理worker進程來實現(xiàn)重啟服務、平滑升級、更換日志文件、配置文件實時生效等功能。worker用來處理基本的網(wǎng)絡事件，worker之間是平等的，他們共同競爭來處理來自客戶端的請求。

nginx的進程模型如圖所示：

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

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

每個worker進程都有一個獨立的連接池，連接池的大小是worker_connections。這里的連接池里面保存的其實不是真實的連接，它只是一個worker_connections大小的一個ngx_connection_t結(jié)構(gòu)的數(shù)組。并且，nginx會通過一個鏈表free_connections來保存所有的空閑ngx_connection_t，每次獲取一個連接時，就從空閑連接鏈表中獲取一個，用完后，再放回空閑連接鏈表里面。一個nginx能建立的最大連接數(shù)，應該是worker_connections * worker_processes。當然，這里說的是最大連接數(shù)，對于HTTP請求本地資源來說，能夠支持的最大并發(fā)數(shù)量是worker_connections * worker_processes，而如果是HTTP作為反向代理來說，最大并發(fā)數(shù)量應該是worker_connections * worker_processes/2。因為作為反向代理服務器，每個并發(fā)會建立與客戶端的連接和與后端服務的連接，會占用兩個連接。

Nginx處理HTTP請求流程

　　http請求是典型的請求-響應類型的的網(wǎng)絡協(xié)議。http是文件協(xié)議，所以我們在分析請求行與請求頭，以及輸出響應行與響應頭，往往是一行一行的進行處理。通常在一個連接建立好后，讀取一行數(shù)據(jù)，分析出請求行中包含的method、uri、http_version信息。然后再一行一行處理請求頭，并根據(jù)請求method與請求頭的信息來決定是否有請求體以及請求體的長度，然后再去讀取請求體。得到請求后，我們處理請求產(chǎn)生需要輸出的數(shù)據(jù)，然后再生成響應行，響應頭以及響應體。在將響應發(fā)送給客戶端之后，一個完整的請求就處理完了。

處理流程圖：

以上就是詳解Nginx 工作原理的詳細內(nèi)容，更多關(guān)于Nginx 工作原理的資料請關(guān)注腳本之家其它相關(guān)文章！