NGINX以高性能的負(fù)載均衡器，緩存，和web服務(wù)器聞名，驅(qū)動(dòng)了全球超過 40% 最繁忙的網(wǎng)站，因此

有一定的參考價(jià)值，有需要的朋友可以參考一下，希望對(duì)大家有所幫助

一. Nginx的模塊與工作原理

Nginx由內(nèi)核和模塊組成，其中，內(nèi)核的設(shè)計(jì)非常微小和簡潔，完成的工作也非常簡單，僅僅通過查找配置文件將客戶端請(qǐng)求映射到一個(gè)location block（location是Nginx配置中的一個(gè)指令，用于URL匹配），而在這個(gè)location中所配置的每個(gè)指令將會(huì)啟動(dòng)不同的模塊去完成相應(yīng)的工作。

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模塊。

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

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

Handlers（處理器模塊）。此類模塊直接處理請(qǐng)求，并進(jìn)行輸出內(nèi)容和修改headers信息等操作。Handlers處理器模塊一般只能有一個(gè)。

Filters （過濾器模塊）。此類模塊主要對(duì)其他處理器模塊輸出的內(nèi)容進(jìn)行修改操作，最后由Nginx輸出。

Proxies （代理類模塊）。此類模塊是Nginx的HTTP Upstream之類的模塊，這些模塊主要與后端一些服務(wù)比如FastCGI等進(jìn)行交互，實(shí)現(xiàn)服務(wù)代理和負(fù)載均衡等功能。

圖1-1展示了Nginx模塊常規(guī)的HTTP請(qǐng)求和響應(yīng)的過程。

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

Nginx的模塊直接被編譯進(jìn)Nginx，因此屬于靜態(tài)編譯方式。啟動(dòng)Nginx后，Nginx的模塊被自動(dòng)加載，不像Apache，首先將模塊編譯為一個(gè)so文件，然后在配置文件中指定是否進(jìn)行加載。在解析配置文件時(shí)，Nginx的每個(gè)模塊都有可能去處理某個(gè)請(qǐng)求，但是同一個(gè)處理請(qǐng)求只能由一個(gè)模塊來完成。

二. Nginx的進(jìn)程模型

在工作方式上，Nginx分為單工作進(jìn)程和多工作進(jìn)程兩種模式。在單工作進(jìn)程模式下，除主進(jìn)程外，還有一個(gè)工作進(jìn)程，工作進(jìn)程是單線程的；在多工作進(jìn)程模式下，每個(gè)工作進(jìn)程包含多個(gè)線程。Nginx默認(rèn)為單工作進(jìn)程模式。

Nginx在啟動(dòng)后，會(huì)有一個(gè)master進(jìn)程和多個(gè)worker進(jìn)程。

1、master進(jìn)程：管理進(jìn)程

master進(jìn)程主要用來管理worker進(jìn)程，具體包括如下4個(gè)主要功能：
（1）接收來自外界的信號(hào)。
（2）向各worker進(jìn)程發(fā)送信號(hào)。
（3）監(jiān)控woker進(jìn)程的運(yùn)行狀態(tài)。
（4）當(dāng)woker進(jìn)程退出后（異常情況下），會(huì)自動(dòng)重新啟動(dòng)新的woker進(jìn)程。

用戶交互接口：master進(jìn)程充當(dāng)整個(gè)進(jìn)程組與用戶的交互接口，同時(shí)對(duì)進(jìn)程進(jìn)行監(jiān)護(hù)。它不需要處理網(wǎng)絡(luò)事件，不負(fù)責(zé)業(yè)務(wù)的執(zhí)行，只會(huì)通過管理worker進(jìn)程來實(shí)現(xiàn)重啟服務(wù)、平滑升級(jí)、更換日志文件、配置文件實(shí)時(shí)生效等功能。

重啟work進(jìn)程：我們要控制nginx，只需要通過kill向master進(jìn)程發(fā)送信號(hào)就行了。比如kill -HUP pid，則是告訴nginx，從容地重啟nginx，我們一般用這個(gè)信號(hào)來重啟nginx，或重新加載配置，因?yàn)槭菑娜莸刂貑ⅲ虼朔?wù)是不中斷的。

master進(jìn)程在接收到HUP信號(hào)后是怎么做的呢？

1）、首先master進(jìn)程在接到信號(hào)后，會(huì)先重新加載配置文件，然后再啟動(dòng)新的worker進(jìn)程，并向所有老的worker進(jìn)程發(fā)送信號(hào)，告訴他們可以光榮退休了。

2）、新的worker在啟動(dòng)后，就開始接收新的請(qǐng)求，而老的worker在收到來自master的信號(hào)后，就不再接收新的請(qǐng)求，并且在當(dāng)前進(jìn)程中的所有未處理完的請(qǐng)求處理完成后，再退出。

直接給master進(jìn)程發(fā)送信號(hào)，這是比較傳統(tǒng)的操作方式，nginx在0.8版本之后，引入了一系列命令行參數(shù)，來方便我們管理。比如，./nginx -s reload，就是來重啟nginx，./nginx -s stop，就是來停止nginx的運(yùn)行。如何做到的呢？我們還是拿reload來說，我們看到，執(zhí)行命令時(shí)，我們是啟動(dòng)一個(gè)新的nginx進(jìn)程，而新的nginx進(jìn)程在解析到reload參數(shù)后，就知道我們的目的是控制nginx來重新加載配置文件了，它會(huì)向master進(jìn)程發(fā)送信號(hào)，然后接下來的動(dòng)作，就和我們直接向master進(jìn)程發(fā)送信號(hào)一樣了。

2、worker進(jìn)程：處理請(qǐng)求

而基本的網(wǎng)絡(luò)事件，則是放在worker進(jìn)程中來處理了。多個(gè)worker進(jìn)程之間是對(duì)等的，他們同等競爭來自客戶端的請(qǐng)求，各進(jìn)程互相之間是獨(dú)立的。一個(gè)請(qǐng)求，只可能在一個(gè)worker進(jìn)程中處理，一個(gè)worker進(jìn)程，不可能處理其它進(jìn)程的請(qǐng)求。worker進(jìn)程的個(gè)數(shù)是可以設(shè)置的，一般我們會(huì)設(shè)置與機(jī)器cpu核數(shù)一致，這里面的原因與nginx的進(jìn)程模型以及事件處理模型是分不開的。

worker進(jìn)程之間是平等的，每個(gè)進(jìn)程，處理請(qǐng)求的機(jī)會(huì)也是一樣的。當(dāng)我們提供80端口的http服務(wù)時(shí)，一個(gè)連接請(qǐng)求過來，每個(gè)進(jìn)程都有可能處理這個(gè)連接，怎么做到的呢？

Nginx采用異步非阻塞的方式來處理網(wǎng)絡(luò)事件，類似于Libevent，具體過程如下：

1）接收請(qǐng)求：首先，每個(gè)worker進(jìn)程都是從master進(jìn)程fork過來，在master進(jìn)程建立好需要listen的socket（listenfd）之后，然后再fork出多個(gè)worker進(jìn)程。所有worker進(jìn)程的listenfd會(huì)在新連接到來時(shí)變得可讀，每個(gè)work進(jìn)程都可以去accept這個(gè)socket（listenfd）。當(dāng)一個(gè)client連接到來時(shí)，所有accept的work進(jìn)程都會(huì)受到通知，但只有一個(gè)進(jìn)程可以accept成功，其它的則會(huì)accept失敗。為保證只有一個(gè)進(jìn)程處理該連接，Nginx提供了一把共享鎖accept_mutex來保證同一時(shí)刻只有一個(gè)work進(jìn)程在accept連接。所有worker進(jìn)程在注冊(cè)listenfd讀事件前搶accept_mutex，搶到互斥鎖的那個(gè)進(jìn)程注冊(cè)listenfd讀事件，在讀事件里調(diào)用accept接受該連接。

2）處理請(qǐng)求：當(dāng)一個(gè)worker進(jìn)程在accept這個(gè)連接之后，就開始讀取請(qǐng)求，解析請(qǐng)求，處理請(qǐng)求，產(chǎn)生數(shù)據(jù)后，再返回給客戶端，最后才斷開連接，這樣一個(gè)完整的請(qǐng)求就是這樣的了。

我們可以看到，一個(gè)請(qǐng)求，完全由worker進(jìn)程來處理，而且只在一個(gè)worker進(jìn)程中處理。worker進(jìn)程之間是平等的，每個(gè)進(jìn)程，處理請(qǐng)求的機(jī)會(huì)也是一樣的。

nginx的進(jìn)程模型，可以由下圖來表示：

三. Nginx為啥性能高－多進(jìn)程IO模型

參考http://mp.weixin.qq.com/s?__biz=MjM5NTg2NTU0Ng==&mid=407889757&idx=3&sn=cfa8a70a5fd2a674a91076f67808273c&scene=23&srcid=0401aeJQEraSG6uvLj69Hfve#rd

1、nginx采用多進(jìn)程模型好處

首先，對(duì)于每個(gè)worker進(jìn)程來說，獨(dú)立的進(jìn)程，不需要加鎖，所以省掉了鎖帶來的開銷，同時(shí)在編程以及問題查找時(shí)，也會(huì)方便很多。

其次，采用獨(dú)立的進(jìn)程，可以讓互相之間不會(huì)影響，一個(gè)進(jìn)程退出后，其它進(jìn)程還在工作，服務(wù)不會(huì)中斷，master進(jìn)程則很快啟動(dòng)新的worker進(jìn)程。當(dāng)然，worker進(jìn)程的異常退出，肯定是程序有bug了，異常退出，會(huì)導(dǎo)致當(dāng)前worker上的所有請(qǐng)求失敗，不過不會(huì)影響到所有請(qǐng)求，所以降低了風(fēng)險(xiǎn)。

2、nginx多進(jìn)程事件模型：異步非阻塞

雖然nginx采用多worker的方式來處理請(qǐng)求，每個(gè)worker里面只有一個(gè)主線程，那能夠處理的并發(fā)數(shù)很有限啊，多少個(gè)worker就能處理多少個(gè)并發(fā)，何來高并發(fā)呢？非也，這就是nginx的高明之處，nginx采用了異步非阻塞的方式來處理請(qǐng)求，也就是說，nginx是可以同時(shí)處理成千上萬個(gè)請(qǐng)求的。一個(gè)worker進(jìn)程可以同時(shí)處理的請(qǐng)求數(shù)只受限于內(nèi)存大小，而且在架構(gòu)設(shè)計(jì)上，不同的worker進(jìn)程之間處理并發(fā)請(qǐng)求時(shí)幾乎沒有同步鎖的限制，worker進(jìn)程通常不會(huì)進(jìn)入睡眠狀態(tài)，因此，當(dāng)Nginx上的進(jìn)程數(shù)與CPU核心數(shù)相等時(shí)（最好每一個(gè)worker進(jìn)程都綁定特定的CPU核心），進(jìn)程間切換的代價(jià)是最小的。

而apache的常用工作方式（apache也有異步非阻塞版本，但因其與自帶某些模塊沖突，所以不常用），每個(gè)進(jìn)程在一個(gè)時(shí)刻只處理一個(gè)請(qǐng)求，因此，當(dāng)并發(fā)數(shù)上到幾千時(shí)，就同時(shí)有幾千的進(jìn)程在處理請(qǐng)求了。這對(duì)操作系統(tǒng)來說，是個(gè)不小的挑戰(zhàn)，進(jìn)程帶來的內(nèi)存占用非常大，進(jìn)程的上下文切換帶來的cpu開銷很大，自然性能就上不去了，而這些開銷完全是沒有意義的。

為什么nginx可以采用異步非阻塞的方式來處理呢，或者異步非阻塞到底是怎么回事呢？具體請(qǐng)看：使用 libevent 和 libev 提高網(wǎng)絡(luò)應(yīng)用性能——I/O模型演進(jìn)變化史

我們先回到原點(diǎn)，看看一個(gè)請(qǐng)求的完整過程:首先，請(qǐng)求過來，要建立連接，然后再接收數(shù)據(jù)，接收數(shù)據(jù)后，再發(fā)送數(shù)據(jù)。

具體到系統(tǒng)底層，就是讀寫事件，而當(dāng)讀寫事件沒有準(zhǔn)備好時(shí)，必然不可操作，如果不用非阻塞的方式來調(diào)用，那就得阻塞調(diào)用了，事件沒有準(zhǔn)備好，那就只能等了，等事件準(zhǔn)備好了，你再繼續(xù)吧。阻塞調(diào)用會(huì)進(jìn)入內(nèi)核等待，cpu就會(huì)讓出去給別人用了，對(duì)單線程的worker來說，顯然不合適，當(dāng)網(wǎng)絡(luò)事件越多時(shí)，大家都在等待呢，cpu空閑下來沒人用，cpu利用率自然上不去了，更別談高并發(fā)了。好吧，你說加進(jìn)程數(shù)，這跟apache的線程模型有什么區(qū)別，注意，別增加無謂的上下文切換。所以，在nginx里面，最忌諱阻塞的系統(tǒng)調(diào)用了。不要阻塞，那就非阻塞嘍。非阻塞就是，事件沒有準(zhǔn)備好，馬上返回EAGAIN，告訴你，事件還沒準(zhǔn)備好呢，你慌什么，過會(huì)再來吧。好吧，你過一會(huì)，再來檢查一下事件，直到事件準(zhǔn)備好了為止，在這期間，你就可以先去做其它事情，然后再來看看事件好了沒。雖然不阻塞了，但你得不時(shí)地過來檢查一下事件的狀態(tài)，你可以做