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

Nginx是一款輕量級的Web 服務(wù)器/反向代理服務(wù)器及電子郵件（IMAP/POP3）代理服務(wù)器，并在一個BSD-like協(xié)議下發(fā)行。由俄羅斯的程序設(shè)計師Igor Sysoev所開發(fā)，供俄國大型的入口網(wǎng)站及搜索引擎Rambler使用。其特點(diǎn)是占有內(nèi)存少，并發(fā)能力強(qiáng)，事實(shí)上nginx的并發(fā)能力確實(shí)在同類型的網(wǎng)頁服務(wù)器中表現(xiàn)較好，中國大陸使用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ā)布。一般情況下，對于新建站點(diǎn)，建議使用最新穩(wěn)定版作為生產(chǎn)版本，已有站點(diǎn)的升級急迫性不高。Nginx 的源代碼使用2-clause BSD-like license。

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

一個完整的代理請求過程為：客戶端首先與代理服務(wù)器創(chuàng)建連接，接著根據(jù)代理服務(wù)器所使用的代理協(xié)議，請求對目標(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ù)器之間的另一臺服務(wù)器，有了它之后，瀏覽器不是直接到Web服務(wù)器去取回網(wǎng)頁而是向代理服務(wù)器發(fā)出請求，信號會先送到代理服務(wù)器，由代理服務(wù)器來取回瀏覽器所需要的信息并傳送給你的瀏覽器。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.高度模塊化的設(shè)計，編寫模塊相對簡單

4.配置簡潔易懂，正則配置讓很多事情變得簡單

對于一個基本的web服務(wù)器來說，事件通常有三種類型，網(wǎng)絡(luò)事件、信號、定時器。

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

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

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

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

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

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

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

（4）與多線程的比較：

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

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

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

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

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

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

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

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

Nginx在啟動后，會有一個master進(jìn)程和多個worker進(jìn)程。master進(jìn)程主要用來管理worker進(jìn)程，包含：接收來自外界的信號，向各worker進(jìn)程發(fā)送信號，監(jiān)控worker進(jìn)程的運(yùn)行狀態(tài)，當(dāng)worker進(jìn)程退出后(異常情況下)，會自動重新啟動新的worker進(jìn)程。而基本的網(wǎng)絡(luò)事件，則是放在worker進(jìn)程中來處理了。多個worker進(jìn)程之間是對等的，他們同等競爭來自客戶端的請求，各進(jìn)程互相之間是獨(dú)立的。一個請求，只可能在一個worker進(jìn)程中處理，一個worker進(jìn)程，不可能處理其它進(jìn)程的請求。worker進(jìn)程的個數(shù)是可以設(shè)置的，一般我們會設(shè)置與機(jī)器cpu核數(shù)一致，這里面的原因與Nginx的進(jìn)程模型以及事件處理模型是分不開的。Nginx的進(jìn)程模型，可以由下圖來表示：

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

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

對于每個worker進(jìn)程來說，獨(dú)立的進(jìn)程，不需要加鎖，所以省掉了鎖帶來的開銷，同時在編程以及問題查找時，也會方便很多。其次，采用獨(dú)立的進(jìn)程，可以讓互相之間不會影響，一個進(jìn)程退出后，其它進(jìn)程還在工作，服務(wù)不會中斷，master進(jìn)程則很快啟動新的worker進(jìn)程。當(dāng)然，worker進(jìn)程的異常退出，肯定是程序有bug了，異常退出，會導(dǎo)致當(dāng)前worker上的所有請求失敗，不過不會影響到所有請求，所以降低了風(fēng)險。

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

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

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

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

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

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

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

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

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

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

3.處理request的header和body。

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

5.完成request的處理。

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

[root@localhost ~]# yum -y groupinstall "Development Tools" "Server Platform Development" 安裝開發(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

修改歡迎頁面

[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)聽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)試及定位問題相關(guān)的配置

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

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

    Syntax: user user [group]; 

    Default:user nobody nobody; 

    Context: main 

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

    Syntax: pid file; 

    Default:pid nginx.pid; 

    Context:main 

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

    Syntax: include file | mask; 

    Default:— 

    Context:any 

4、load_module file; # 指明要裝載的動態(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                     

如果只有兩個進(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號CPU 

        00000010：1號CPU 

        00000100: 2號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)先級；[-20,20]

    Syntax: worker_priority number; 

    Default:worker_priority 0; 

    Context:main 

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

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

[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)先級為-5
nginx 43362 2 -5 優(yōu)先級為-54、worker_rlimit_nofile number; #　worker進(jìn)程所能夠打開的文件數(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]; # 定義錯誤日志文件路徑與級別

    Syntax: error_log file [level]; 

    Default:error_log logs/error.log error; 

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

events { 

    … 

} 

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

    Syntax: worker_connections number; 

    Default:worker_connections 512; 

    Context:events 

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

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

    Syntax: use method; 

    Default:— 

    Context:events 

        use epoll; 

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

    Syntax: accept_mutex on | off; 

    Default:accept_mutex off; 

    Context:events 

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

event {

…

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

http {

…

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

mail {

…

}

stream {

…

}

http {

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

}