摘要：是由為俄羅斯訪問(wèn)量第二的站點(diǎn)開(kāi)發(fā)的，第一個(gè)公開(kāi)版本發(fā)布于年月日。盡管在這個(gè)虛擬的環(huán)境下，防火墻和反向代理的共同作用保護(hù)了原始資源服務(wù)器，但用戶并不知情。穩(wěn)定性高用于反向代理，宕機(jī)的概率微乎其微。

http://www.cnblogs.com/wylhome/p/6057198.html
http://tengine.taobao.org/book/chapter_02.html
http://blog.csdn.net/justin_yaphet/article/details/47910439

Nginx (engine x) 是一個(gè)高性能的HTTP和反向代理服務(wù)器，也是一個(gè)IMAP/POP3/SMTP服務(wù)器。Nginx是由Igor Sysoev為俄羅斯訪問(wèn)量第二的Rambler.ru站點(diǎn)開(kāi)發(fā)的，第一個(gè)公開(kāi)版本0.1.0發(fā)布于2004年10月4日。其將源代碼以類BSD許可證的形式發(fā)布，因它的穩(wěn)定性、豐富的功能集、示例配置文件和低系統(tǒng)資源的消耗而聞名。

Nginx是一款輕量級(jí)的Web 服務(wù)器/反向代理服務(wù)器及電子郵件（IMAP/POP3）代理服務(wù)器，并在一個(gè)BSD-like協(xié)議下發(fā)行。由俄羅斯的程序設(shè)計(jì)師Igor Sysoev所開(kāi)發(fā)，供俄國(guó)大型的入口網(wǎng)站及搜索引擎Rambler使用。其特點(diǎn)是占有內(nèi)存少，并發(fā)能力強(qiáng)，事實(shí)上nginx的并發(fā)能力確實(shí)在同類型的網(wǎng)頁(yè)服務(wù)器中表現(xiàn)較好，中國(guó)大陸使用nginx網(wǎng)站用戶有：百度、京東、新浪、網(wǎng)易、騰訊、淘寶等。

Nginx可以在大多數(shù) UnixLinux OS上編譯運(yùn)行，并有Windows移植版。 Nginx 的1.4.0穩(wěn)定版已經(jīng)于2013年4月24日發(fā)布，2016年10月18日，Nginx1.10.2 穩(wěn)定版本發(fā)布。一般情況下，對(duì)于新建站點(diǎn)，建議使用最新穩(wěn)定版作為生產(chǎn)版本，已有站點(diǎn)的升級(jí)急迫性不高。Nginx 的源代碼使用2-clause BSD-like license。

一般是指局域網(wǎng)內(nèi)部的機(jī)器通過(guò)代理服務(wù)器發(fā)送請(qǐng)求到互聯(lián)網(wǎng)上的服務(wù)器,代理服務(wù)器一般作用在客戶端。

一個(gè)完整的代理請(qǐng)求過(guò)程為：客戶端首先與代理服務(wù)器創(chuàng)建連接，接著根據(jù)代理服務(wù)器所使用的代理協(xié)議，請(qǐng)求對(duì)目標(biāo)服務(wù)器創(chuàng)建連接、或者獲得目標(biāo)服務(wù)器的指定資源。 Web代理（proxy）服務(wù)器是網(wǎng)絡(luò)的中間實(shí)體。 代理位于Web客戶端和Web服務(wù)器之間，扮演“中間人”的角色。HTTP的代理服務(wù)器即是Web服務(wù)器又是Web客戶端。

代理服務(wù)器是介于客戶端和Web服務(wù)器之間的另一臺(tái)服務(wù)器，有了它之后，瀏覽器不是直接到Web服務(wù)器去取回網(wǎng)頁(yè)而是向代理服務(wù)器發(fā)出請(qǐng)求，信號(hào)會(huì)先送到代理服務(wù)器，由代理服務(wù)器來(lái)取回瀏覽器所需要的信息并傳送給你的瀏覽器。

是一個(gè)位于客戶端和原始服務(wù)器(origin server)之間的服務(wù)器，為了從原始服務(wù)器取得內(nèi)容，客戶端向代理發(fā)送一個(gè)請(qǐng)求并指定目標(biāo)(原始服務(wù)器)，然后代理向原始服務(wù)器轉(zhuǎn)交請(qǐng)求并將獲得的內(nèi)容返回給客戶端?？蛻舳吮仨氁M(jìn)行一些特別的設(shè)置才能使用正向代理。

在服務(wù)器端接受客戶端的請(qǐng)求，然后把請(qǐng)求分發(fā)給具體的服務(wù)器進(jìn)行處理，然后再將服務(wù)器的響應(yīng)結(jié)果反饋給客戶端。Nginx就是其中的一種反向代理服務(wù)器軟件。

說(shuō)明：客戶端必須設(shè)置正向代理服務(wù)器，當(dāng)然前提是要知道正向代理服務(wù)器的IP地址，還有代理程序的端口。

反向代理正好與正向代理相反，對(duì)于客戶端而言代理服務(wù)器就像是原始服務(wù)器，并且客戶端不需要進(jìn)行任何特別的設(shè)置。客戶端向反向代理的命名空間(name-space)中的內(nèi)容發(fā)送普通請(qǐng)求，接著反向代理將判斷向何處(原始服務(wù)器)轉(zhuǎn)交請(qǐng)求，并將獲得的內(nèi)容返回給客戶端。

用戶A始終認(rèn)為它訪問(wèn)的是原始服務(wù)器B而不是代理服務(wù)器Z，但實(shí)用際上反向代理服務(wù)器接受用戶A的應(yīng)答，從原始資源服務(wù)器B中取得用戶A的需求資源，然后發(fā)送給用戶A。由于防火墻的作用，只允許代理服務(wù)器Z訪問(wèn)原始資源服務(wù)器B。盡管在這個(gè)虛擬的環(huán)境下，防火墻和反向代理的共同作用保護(hù)了原始資源服務(wù)器B，但用戶A并不知情。

跨平臺(tái)：Nginx 可以在大多數(shù) Unix like OS編譯運(yùn)行，而且也有Windows的移植版本。

配置異常簡(jiǎn)單：非常容易上手。配置風(fēng)格跟程序開(kāi)發(fā)一樣，神一般的配置

非阻塞、高并發(fā)連接：數(shù)據(jù)復(fù)制時(shí)，磁盤(pán)I/O的第一階段是非阻塞的。官方測(cè)試能夠支撐5萬(wàn)并發(fā)連接，在實(shí)際生產(chǎn)環(huán)境中跑到2～3萬(wàn)并發(fā)連接數(shù).(這得益于Nginx使用了最新的epoll模型)

事件驅(qū)動(dòng)：通信機(jī)制采用epoll模型，支持更大的并發(fā)連接。

高并發(fā)：Nginx 是一個(gè)很強(qiáng)大的高性能Web和反向代理服務(wù)器，它具有很多非常優(yōu)越的特性。在連接高并發(fā)的情況下，Nginx是Apache服務(wù)器不錯(cuò)的替代品，能夠支持高達(dá) 50,000 個(gè)并發(fā)連接數(shù)的響應(yīng)。

負(fù)載均衡器：Nginx作為負(fù)載均衡服務(wù)器：Nginx 既可以在內(nèi)部直接支持 Rails 和 PHP 程序?qū)ν膺M(jìn)行服務(wù)，也可以支持作為 HTTP代理服務(wù)器對(duì)外進(jìn)行服務(wù)。

代理服務(wù)器：Nginx本身就是一個(gè)反向代理服務(wù)器，可支持郵件服務(wù)器代理以及http代理

1.輕量級(jí)，同樣起web 服務(wù)，比apache 占用更少的內(nèi)存及資源

2.抗并發(fā)，nginx 處理請(qǐng)求是異步非阻塞的，而apache 則是阻塞型的，在高并發(fā)下nginx 能保持低資源低消耗高性能

3.高度模塊化的設(shè)計(jì)，編寫(xiě)模塊相對(duì)簡(jiǎn)單

4.配置簡(jiǎn)潔易懂，正則配置讓很多事情變得簡(jiǎn)單

對(duì)于一個(gè)基本的web服務(wù)器來(lái)說(shuō)，事件通常有三種類型，網(wǎng)絡(luò)事件、信號(hào)、定時(shí)器。

首先看一個(gè)請(qǐng)求的基本過(guò)程：建立連接—接收數(shù)據(jù)—發(fā)送數(shù)據(jù) 。

再次看系統(tǒng)底層的操作 ：上述過(guò)程（建立連接—接收數(shù)據(jù)—發(fā)送數(shù)據(jù)）在系統(tǒng)底層就是讀寫(xiě)事件。

（1）如果采用阻塞調(diào)用的方式，當(dāng)讀寫(xiě)事件沒(méi)有準(zhǔn)備好時(shí)，必然不能夠進(jìn)行讀寫(xiě)事件，那么久只好等待，等事件準(zhǔn)備好了，才能進(jìn)行讀寫(xiě)事件。那么請(qǐng)求就會(huì)被耽擱 。阻塞調(diào)用會(huì)進(jìn)入內(nèi)核等待，cpu就會(huì)讓出去給別人用了，對(duì)單線程的worker來(lái)說(shuō)，顯然不合適，當(dāng)網(wǎng)絡(luò)事件越多時(shí)，大家都在等待呢，cpu空閑下來(lái)沒(méi)人用，cpu利用率自然上不去了，更別談高并發(fā)了 。

（2）既然沒(méi)有準(zhǔn)備好阻塞調(diào)用不行，那么采用非阻塞方式。非阻塞就是，事件，馬上返回EAGAIN， 告訴你，事件還沒(méi)準(zhǔn)備好呢，你慌什么，過(guò)會(huì)再來(lái)吧。好吧，你過(guò)一會(huì)，再來(lái)檢查一下事件，直到事件準(zhǔn)備好了為止，在這期間，你就可以先去做其它事情，然后再 來(lái)看看事件好了沒(méi)。雖然不阻塞了，但你得不時(shí)地過(guò)來(lái)檢查一下事件的狀態(tài)，你可以做更多的事情了，但帶來(lái)的開(kāi)銷也是不小的

小結(jié)：非阻塞通過(guò)不斷檢查事件的狀態(tài)來(lái)判斷是否進(jìn)行讀寫(xiě)操作，這樣帶來(lái)的開(kāi)銷很大。

（3）因此才有了異步非阻塞的事件處理機(jī)制。具體到系統(tǒng)調(diào)用就是像select/poll/epoll/kqueue這樣的系統(tǒng)調(diào)用。他們提供了一種機(jī)制，讓你可以同時(shí)監(jiān)控多個(gè)事件，調(diào)用他們是阻塞的，但可以設(shè)置超時(shí)時(shí)間，在超時(shí)時(shí)間之內(nèi)，如果有事件準(zhǔn)備好了，就返回。這種機(jī)制解決了我們上面兩個(gè)問(wèn)題。

以epoll為例：當(dāng)事件沒(méi)有準(zhǔn)備好時(shí)，就放入epoll(隊(duì)列)里面。如果有事件準(zhǔn)備好了，那么就去處理；如果事件返回的是EAGAIN，那么繼續(xù)將其放入epoll里面。從而，只要有事件準(zhǔn)備好了，我們就去處理她，只有當(dāng)所有時(shí)間都沒(méi)有準(zhǔn)備好時(shí)，才在epoll里 面等著。這樣，我們就可以并發(fā)處理大量的并發(fā)了，當(dāng)然，這里的并發(fā)請(qǐng)求，是指未處理完的請(qǐng)求，線程只有一個(gè)，所以同時(shí)能處理的請(qǐng)求當(dāng)然只有一個(gè)了，只是在 請(qǐng)求間進(jìn)行不斷地切換而已，切換也是因?yàn)楫惒绞录礈?zhǔn)備好，而主動(dòng)讓出的。這里的切換是沒(méi)有任何代價(jià)，可以理解為循環(huán)處理多個(gè)準(zhǔn)備好的事件

（4）與多線程的比較：

 與多線程相比，這種事件處理方式是有很大的優(yōu)勢(shì)的，不需要?jiǎng)?chuàng)建線程，每個(gè)請(qǐng)求占用的內(nèi)存也很少，沒(méi)有上下文切換，事件處理非常的輕量級(jí)。并發(fā)數(shù)再多也不會(huì)導(dǎo)致無(wú)謂的資源浪費(fèi)（上下文切換）。 

小結(jié)：通過(guò)異步非阻塞的事件處理機(jī)制，Nginx實(shí)現(xiàn)由進(jìn)程循環(huán)處理多個(gè)準(zhǔn)備好的事件，從而實(shí)現(xiàn)高并發(fā)和輕量級(jí)。

master/worker結(jié)構(gòu)：一個(gè)master進(jìn)程，生成一個(gè)或多個(gè)worker進(jìn)程

內(nèi)存消耗?。禾幚泶蟛l(fā)的請(qǐng)求內(nèi)存消耗非常小。在3萬(wàn)并發(fā)連接下，開(kāi)啟的10個(gè)Nginx 進(jìn)程才消耗150M內(nèi)存（15M*10=150M） 成本低廉：Nginx為開(kāi)源軟件，可以免費(fèi)使用。而購(gòu)買(mǎi)F5 BIG-IP、NetScaler等硬件負(fù)載均衡交換機(jī)則需要十多萬(wàn)至幾十萬(wàn)人民幣

內(nèi)置的健康檢查功能：如果 Nginx Proxy 后端的某臺(tái) Web 服務(wù)器宕機(jī)了，不會(huì)影響前端訪問(wèn)。

節(jié)省帶寬：支持 GZIP 壓縮，可以添加瀏覽器本地緩存的 Header 頭。

穩(wěn)定性高：用于反向代理，宕機(jī)的概率微乎其微。

Nginx在啟動(dòng)后，在Unix系統(tǒng)中會(huì)以daemon的方式在后臺(tái)運(yùn)行，后臺(tái)進(jìn)程包含一個(gè)master進(jìn)程和多個(gè)worker進(jìn)程。我們也可以手動(dòng)地關(guān)掉后臺(tái)模式，讓Nginx在前臺(tái)運(yùn)行，并且通過(guò)配置讓Nginx取消master進(jìn)程，從而可以使Nginx以單進(jìn)程方式運(yùn)行。很顯然，生產(chǎn)環(huán)境下我們肯定不會(huì)這么做，所以關(guān)閉后臺(tái)模式，一般是用來(lái)調(diào)試用的，Nginx是以多進(jìn)程的方式來(lái)工作的，當(dāng)然Nginx也是支持多線程的方式的，只是我們主流的方式還是多進(jìn)程的方式，也是Nginx的默認(rèn)方式。Nginx采用多進(jìn)程的方式有諸多好處。

Nginx在啟動(dòng)后，會(huì)有一個(gè)master進(jìn)程和多個(gè)worker進(jìn)程。master進(jìn)程主要用來(lái)管理worker進(jìn)程，包含：接收來(lái)自外界的信號(hào)，向各worker進(jìn)程發(fā)送信號(hào)，監(jiān)控worker進(jìn)程的運(yùn)行狀態(tài)，當(dāng)worker進(jìn)程退出后(異常情況下)，會(huì)自動(dòng)重新啟動(dòng)新的worker進(jìn)程。而基本的網(wǎng)絡(luò)事件，則是放在worker進(jìn)程中來(lái)處理了。多個(gè)worker進(jìn)程之間是對(duì)等的，他們同等競(jìng)爭(zhēng)來(lái)自客戶端的請(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)程模型以及事件處理模型是分不開(kāi)的。Nginx的進(jìn)程模型，可以由下圖來(lái)表示：

master進(jìn)程會(huì)接收來(lái)自外界發(fā)來(lái)的信號(hào)，再根據(jù)信號(hào)做不同的事情。所以我們要控制Nginx，只需要通過(guò)kill向master進(jìn)程發(fā)送信號(hào)就行了。比如kill -HUP pid，則是告訴Nginx，從容地重啟Nginx，我們一般用這個(gè)信號(hào)來(lái)重啟Nginx，或重新加載配置，因?yàn)槭菑娜莸刂貑ⅲ虼朔?wù)是不中斷的。master進(jìn)程在接收到HUP信號(hào)后是怎么做的呢？首先master進(jìn)程在接到信號(hào)后，會(huì)先重新加載配置文件，然后再啟動(dòng)新的worker進(jìn)程，并向所有老的worker進(jìn)程發(fā)送信號(hào)，告訴他們可以光榮退休了。新的worker在啟動(dòng)后，就開(kāi)始接收新的請(qǐng)求，而老的worker在收到來(lái)自master的信號(hào)后，就不再接收新的請(qǐng)求，并且在當(dāng)前進(jìn)程中的所有未處理完的請(qǐng)求處理完成后，再退出。當(dāng)然，直接給master進(jìn)程發(fā)送信號(hào)，這是比較老的操作方式，Nginx在0.8版本之后，引入了一系列命令行參數(shù)，來(lái)方便我們管理。比如，./nginx -s reload，就是來(lái)重啟Nginx，./nginx -s stop，就是來(lái)停止Nginx的運(yùn)行。如何做到的呢？我們還是拿reload來(lái)說(shuō)，我們看到，執(zhí)行命令時(shí)，我們是啟動(dòng)一個(gè)新的Nginx進(jìn)程，而新的Nginx進(jìn)程在解析到reload參數(shù)后，就知道我們的目的是控制Nginx來(lái)重新加載配置文件了，它會(huì)向master進(jìn)程發(fā)送信號(hào)，然后接下來(lái)的動(dòng)作，就和我們直接向master進(jìn)程發(fā)送信號(hào)一樣了。

worker進(jìn)程之間是平等的，每個(gè)進(jìn)程，處理請(qǐng)求的機(jī)會(huì)也是一樣的。當(dāng)我們提供80端口的http服務(wù)時(shí)，一個(gè)連接請(qǐng)求過(guò)來(lái)，每個(gè)進(jìn)程都有可能處理這個(gè)連接。每個(gè)worker進(jìn)程都是從master進(jìn)程fork過(guò)來(lái)，在master進(jìn)程里面，先建立好需要listen的socket（listenfd）之后，然后再fork出多個(gè)worker進(jìn)程。所有worker進(jìn)程的listenfd會(huì)在新連接到來(lái)時(shí)變得可讀，為保證只有一個(gè)進(jìn)程處理該連接，所有worker進(jìn)程在注冊(cè)listenfd讀事件前搶accept_mutex，搶到互斥鎖的那個(gè)進(jìn)程注冊(cè)listenfd讀事件，在讀事件里調(diào)用accept接受該連接。當(dāng)一個(gè)worker進(jìn)程在accept這個(gè)連接之后，就開(kāi)始讀取請(qǐng)求，解析請(qǐng)求，處理請(qǐng)求，產(chǎn)生數(shù)據(jù)后，再返回給客戶端，最后才斷開(kāi)連接，這樣一個(gè)完整的請(qǐng)求就是這樣的了。一個(gè)請(qǐng)求，完全由worker進(jìn)程來(lái)處理，而且只在一個(gè)worker進(jìn)程中處理。

對(duì)于每個(gè)worker進(jìn)程來(lái)說(shuō)，獨(dú)立的進(jìn)程，不需要加鎖，所以省掉了鎖帶來(lái)的開(kāi)銷，同時(shí)在編程以及問(wèn)題查找時(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)求失敗，不過(guò)不會(huì)影響到所有請(qǐng)求，所以降低了風(fēng)險(xiǎn)。

nginx的內(nèi)部結(jié)構(gòu)是由核心部分和一系列的功能模塊所組成。這樣劃分是為了使得每個(gè)模塊的功能相對(duì)簡(jiǎn)單，便于開(kāi)發(fā)，同時(shí)也便于對(duì)系統(tǒng)進(jìn)行功能擴(kuò)展。為了便于描述，下文中我們將使用nginx core來(lái)稱呼nginx的核心功能部分。

nginx提供了web服務(wù)器的基礎(chǔ)功能，同時(shí)提供了web服務(wù)反向代理，email服務(wù)反向代理功能。nginx core實(shí)現(xiàn)了底層的通訊協(xié)議，為其他模塊和nginx進(jìn)程構(gòu)建了基本的運(yùn)行時(shí)環(huán)境，并且構(gòu)建了其他各模塊的協(xié)作基礎(chǔ)。除此之外，或者說(shuō)大部分與協(xié)議相關(guān)的，或者應(yīng)用相關(guān)的功能都是在這些模塊中所實(shí)現(xiàn)的。

nginx將各功能模塊組織成一條鏈，當(dāng)有請(qǐng)求到達(dá)的時(shí)候，請(qǐng)求依次經(jīng)過(guò)這條鏈上的部分或者全部模塊，進(jìn)行處理。每個(gè)模塊實(shí)現(xiàn)特定的功能。例如，實(shí)現(xiàn)對(duì)請(qǐng)求解壓縮的模塊，實(shí)現(xiàn)SSI的模塊，實(shí)現(xiàn)與上游服務(wù)器進(jìn)行通訊的模塊，實(shí)現(xiàn)與FastCGI服務(wù)進(jìn)行通訊的模塊。

有兩個(gè)模塊比較特殊，他們居于nginx core和各功能模塊的中間。這兩個(gè)模塊就是http模塊和mail模塊。這2個(gè)模塊在nginx core之上實(shí)現(xiàn)了另外一層抽象，處理與HTTP協(xié)議和email相關(guān)協(xié)議（SMTP/POP3/IMAP）有關(guān)的事件，并且確保這些事件能被以正確的順序調(diào)用其他的一些功能模塊。

目前HTTP協(xié)議是被實(shí)現(xiàn)在http模塊中的，但是有可能將來(lái)被剝離到一個(gè)多帶帶的模塊中，以擴(kuò)展nginx支持SPDY協(xié)議。

nginx使用一個(gè)多進(jìn)程模型來(lái)對(duì)外提供服務(wù)，其中一個(gè)master進(jìn)程，多個(gè)worker進(jìn)程。master進(jìn)程負(fù)責(zé)管理nginx本身和其他worker進(jìn)程。

所有實(shí)際上的業(yè)務(wù)處理邏輯都在worker進(jìn)程。worker進(jìn)程中有一個(gè)函數(shù)，執(zhí)行無(wú)限循環(huán)，不斷處理收到的來(lái)自客戶端的請(qǐng)求，并進(jìn)行處理，直到整個(gè)nginx服務(wù)被停止。

worker進(jìn)程中，ngx_worker_process_cycle()函數(shù)就是這個(gè)無(wú)限循環(huán)的處理函數(shù)。在這個(gè)函數(shù)中，一個(gè)請(qǐng)求的簡(jiǎn)單處理流程如下：

1.操作系統(tǒng)提供的機(jī)制（例如epoll, kqueue等）產(chǎn)生相關(guān)的事件。

2.接收和處理這些事件，如是接受到數(shù)據(jù)，則產(chǎn)生更高層的request對(duì)象。

3.處理request的header和body。

4.產(chǎn)生響應(yīng)，并發(fā)送回客戶端。

5.完成request的處理。

6.重新初始化定時(shí)器及其他事件。

[root@localhost ~]# yum -y groupinstall "Development Tools" "Server Platform Development" 安裝開(kāi)發(fā)包組
[root@localhost ~]# yum -y install pcre-devel openssl-devel zlib-devel #安裝依賴包
[root@localhost ~]# useradd -r nginx # 創(chuàng)建nginx系統(tǒng)用戶
[root@localhost~]#./configure--prefix=/usr/local/nginx--conf-path=/etc/nginx/nginx.conf--error-log-path=/var/log/nginx/error.log--http-log-path=/var/log/nginx/access.log--pid-path=/var/run/nginx.pid--lock-path=/var/run/nginx.lock --user=nginx --group=nginx --with-http_ssl_module --with-http_v2_module --with-http_dav_module --with-http_stub_status_module --with-threads --with-file-aio # 配置nginx
[root@localhost ~]# make #編譯
[root@localhost ~]# make install　　#安裝或設(shè)置連接官網(wǎng)的yum源（官網(wǎng)地址http://nginx.org/packages/cen...）

[root@localhost ~]#vim /etc/yum.repos.d/nginx.repo
[nginx]
name=nginx
baseurl=http://nginx.org/packages/cen...
gpgcheck=0
[root@localhost ~]#yum install nginx
[root@localhost ~]#systemctl start nginx.service

也可從本地epel直接安裝

[root@localhost ~]#yum install nginx
[root@localhost ~]#systemctl start nginx.service

修改歡迎頁(yè)面

[root@nginx1 /etc/nginx]#mkdir /data/nginx/vhost1 -pv
[root@nginx1 /etc/nginx]#vim /data/nginx/vhost1/index.html

Nginx Vhost 1

    listen 80;#監(jiān)聽(tīng)80端口
    server_name www.ilinux.io;#主機(jī)名為www.ilinux.io
    root /data/nginx/vhost1;#路徑

}
[root@nginx1 /etc/nginx]#nginx -t
[root@nginx1 /etc/nginx]#nginx -s reload#重載配置文件
[root@nginx1 /etc/nginx]#vim /etc/hosts
172.16.254.127 www.ilinux.io

主配置文件：nginx.conf

include conf.d/*.conf

fastcgi， uwsgi，scgi等協(xié)議相關(guān)的配置文件

mime.types：支持的mime類型

主程序文件：/usr/sbin/nginx

Unit File：nginx.service

nginx配置文件組成：主配置文件nginx.conf，conf.d/*.conf；

fastcgi，uwsgi，scgi等協(xié)議相關(guān)的配置文件；

mime.types：支持的mime類型

分類：

正常運(yùn)行必備的配置

優(yōu)化性能相關(guān)的配置

用于調(diào)試及定位問(wèn)題相關(guān)的配置

事件驅(qū)動(dòng)相關(guān)的配置

1、user #　指定用于運(yùn)行worker進(jìn)程時(shí)的用戶

    Syntax: user user [group]; 

    Default:user nobody nobody; 

    Context: main 

2、pid /PATH/TO/PID_FILE; # 指定存儲(chǔ)nginx主進(jìn)程進(jìn)程號(hào)碼的文件路徑

    Syntax: pid file; 

    Default:pid nginx.pid; 

    Context:main 

3、include file | mask; # 指明包含進(jìn)來(lái)的其它配置文件片斷

    Syntax: include file | mask; 

    Default:— 

    Context:any 

4、load_module file; # 指明要裝載的動(dòng)態(tài)模塊

    Syntax: load_module file; 

    Default:— 

    Context:main                     

1、worker_processes number | auto; # worker進(jìn)程的數(shù)量；通常應(yīng)該為當(dāng)前主機(jī)的cpu的物理核心數(shù)

    Syntax: worker_processes number | auto; 

    Default:worker_processes 1; 

    Context:main                     

如果只有兩個(gè)進(jìn)程

[root@localhost /etc/nginx]#nginx -t
[root@localhost /etc/nginx]#nginx -s reload

![圖片上傳中...]

[root@localhost /etc/nginx]#nginx -t
[root@localhost /etc/nginx]#nginx -s reload

2、worker_cpu_affinity cpumask …; # 定義worker進(jìn)程和cpu的綁定

    worker_cpu_affinity auto [cpumask]; 

    Default:— 

    Context:main                         

    CPU MASK： 

        00000001：0號(hào)CPU 

        00000010：1號(hào)CPU 

        00000100: 2號(hào)CPU 

        … … 

綁定cpu，默認(rèn)次序0、1、2、3

[root@localhost /etc/nginx]#nginx -t
[root@localhost /etc/nginx]#nginx -s reload

反向綁定cpu，3、2、1、0

[root@localhost /etc/nginx]#nginx -t
[root@localhost /etc/nginx]#nginx -s reload

3、worker_priority number;　# 指定worker進(jìn)程的nice值，設(shè)定worker進(jìn)程優(yōu)先級(jí)；[-20,20]

    Syntax: worker_priority number; 

    Default:worker_priority 0; 

    Context:main 

默認(rèn)優(yōu)先級(jí)

[root@localhost /etc/nginx]#ps axo comm,pid,psr,ni | grep nginx
nginx 4795 2 0
nginx 43059 3 0 優(yōu)先級(jí)為0
nginx 43060 2 0 優(yōu)先級(jí)為0設(shè)定優(yōu)先級(jí)

[root@localhost /etc/nginx]#nginx -t
[root@localhost /etc/nginx]#nginx -s reload
[root@localhost /etc/nginx]#ps axo comm,pid,psr,ni | grep nginx
nginx 4795 2 0
nginx 43361 3 -5 優(yōu)先級(jí)為-5
nginx 43362 2 -5 優(yōu)先級(jí)為-54、worker_rlimit_nofile number; #　worker進(jìn)程所能夠打開(kāi)的文件數(shù)量上限

    Syntax: worker_rlimit_nofile number; 

    Default:— 

    Context:main 

[root@localhost /etc/nginx]#vim nginx.conf

1、daemon on|off; # 是否以守護(hù)進(jìn)程方式運(yùn)行Nignx

    Syntax: daemon on | off; 

    Default:daemon on; 

    Context:main 

2、master_process on|off; # 是否以master/worker模型運(yùn)行nginx；默認(rèn)為on

    Syntax: master_process on | off; 

    Default:master_process on; 

    Context:main 

3、error_log file [level]; # 定義錯(cuò)誤日志文件路徑與級(jí)別

    Syntax: error_log file [level]; 

    Default:error_log logs/error.log error; 

    Context:main, http, mail, stream, server, location 

events { 

    … 

} 

1、worker_connections number; # 每個(gè)worker進(jìn)程所能夠打開(kāi)的最大并發(fā)連接數(shù)數(shù)量

    Syntax: worker_connections number; 

    Default:worker_connections 512; 

    Context:events 

    worker_processes * worker_connections得出最大并發(fā)連接數(shù) 

2、use method; # 指明并發(fā)連接請(qǐng)求的處理方法

    Syntax: use method; 

    Default:— 

    Context:events 

        use epoll; 

3、accept_mutex on | off; # 處理新的連接請(qǐng)求的方法；on意味著由各worker輪流處理新請(qǐng)求，Off意味著每個(gè)新請(qǐng)求的到達(dá)都會(huì)通知所有的worker進(jìn)程；建議使用on

    Syntax: accept_mutex on | off; 

    Default:accept_mutex off; 

    Context:events 

main block：主配置段，也即全局配置段；

event {

…

}：事件驅(qū)動(dòng)相關(guān)的配置；

http {

…

}：http/https 協(xié)議相關(guān)的配置段；

mail {

…

}

stream {

…

}

http {

...
...：各server的公共配置
server {
    ...
}：每個(gè)server用于定義一個(gè)虛擬主機(jī)；
server {
    ...
    listen 
    server_name
    root
    alias
    location [OPERATOR] URL {
        ...
        if CONDITION {
            ...
        }
    }
}

}