當(dāng)我們打開(kāi)手機(jī)訪問(wèn)點(diǎn)評(píng)客戶端的時(shí)候，訪問(wèn)商戶的請(qǐng)求是如何到達(dá)對(duì)應(yīng)某臺(tái)應(yīng)用服務(wù)器的？

當(dāng)有很多XX寬帶的用戶投訴說(shuō)我大點(diǎn)評(píng)某某域名無(wú)法打開(kāi)但是我們卻找不出任何問(wèn)題的時(shí)候，我們就想到會(huì)不會(huì)是寬帶運(yùn)營(yíng)商的問(wèn)題。

今天與大家分享的話題，主要是跟我們的軟負(fù)載集群和Nginx這個(gè)強(qiáng)大的開(kāi)源應(yīng)用有關(guān)系。

當(dāng)我們準(zhǔn)備上線一個(gè)新的業(yè)務(wù)，或者新的功能時(shí)候，除了把代碼發(fā)布的線上生產(chǎn)環(huán)境的應(yīng)用服務(wù)器外，還需要做什么工作才能讓我們的資深吃貨的用戶們可以訪問(wèn)到我們高端大氣上檔次的服務(wù)呢？

用戶是不可能直接跑到我們的IDC機(jī)房插根網(wǎng)線就來(lái)訪問(wèn)我們的內(nèi)部服務(wù)器的，我們答應(yīng)，電信管理IDC的怪叔叔們也不會(huì)答應(yīng)啊。

首先，我們很清楚用戶是通過(guò)dianping.com的域名來(lái)訪問(wèn)我們的站點(diǎn)，同時(shí)通過(guò)我們對(duì)外開(kāi)放的url鏈接來(lái)訪問(wèn)一些新站點(diǎn)或者新功能的頁(yè)面。然后，用戶訪問(wèn)的域名會(huì)通過(guò)DNS服務(wù)被替換為我們對(duì)外的IP地址，這樣才能被網(wǎng)絡(luò)設(shè)備識(shí)別，然后將用戶的請(qǐng)求按照一個(gè)一個(gè)網(wǎng)絡(luò)包發(fā)給我們的網(wǎng)絡(luò)設(shè)備，***網(wǎng)絡(luò)設(shè)備收到這些網(wǎng)絡(luò)數(shù)據(jù)包后，會(huì)將這些數(shù)據(jù)整理后轉(zhuǎn)化為應(yīng)用程序可以理解的數(shù)據(jù)。

數(shù)據(jù)到了我們的核心網(wǎng)絡(luò)設(shè)備被轉(zhuǎn)換為應(yīng)用層的數(shù)據(jù)后，是如何到我們具體某一臺(tái)應(yīng)用服務(wù)器來(lái)處理呢，這就牽涉到我們要講的負(fù)載均衡器了。負(fù)載均衡器如果是硬件設(shè)備的話，那就是我們經(jīng)常提到的負(fù)載均衡設(shè)備，如果是linux服務(wù)器上運(yùn)行的負(fù)載均衡軟件，那就是軟負(fù)載了，如果是集群而不是單機(jī)的話，那就是傳說(shuō)中的負(fù)載均衡集群了。

如下圖是我們 線上生產(chǎn)環(huán)境的用戶請(qǐng)求走向圖：

當(dāng)一個(gè)吃貨通過(guò)瀏覽器或手機(jī)APP訪問(wèn)我們網(wǎng)站的時(shí)候，無(wú)論是訪問(wèn)商戶，添加點(diǎn)評(píng)，購(gòu)買(mǎi)團(tuán)購(gòu)，還是在社區(qū)通過(guò)私信功能與妹子聊天，所有請(qǐng)求都會(huì)經(jīng)過(guò)我們的F5負(fù)載均衡設(shè)備按照設(shè)定的轉(zhuǎn)發(fā)策略（隨機(jī)，權(quán)重，最小連接等）轉(zhuǎn)發(fā)到特定的某臺(tái)應(yīng)用服務(wù)器來(lái)處理，然后再將處理結(jié)果返回給用戶。

好吧，當(dāng)我們說(shuō)了這個(gè)硬件設(shè)備時(shí)候，是不是要談?wù)勔攒浖?shí)現(xiàn)的負(fù)載均衡功能呢，其實(shí)目前在我們PPE環(huán)境（xx機(jī)房，以后的雙IDC運(yùn)行后另一個(gè)生產(chǎn)環(huán)境）運(yùn)行著這樣一套軟負(fù)載集群來(lái)處理用戶的請(qǐng)求（當(dāng)然，現(xiàn)在都是偽造的用戶請(qǐng)求）。

網(wǎng)絡(luò)設(shè)備和Nginx負(fù)載均衡集群中間的F5作為流量管理設(shè)備，做4層（連接層，tcp）流量分發(fā)。

軟負(fù)載實(shí)質(zhì)上是一組nginx集群以及允許用戶管理nginx配置文件的一個(gè)web端。

Nginx ("engine x") 是一個(gè)高性能的 HTTP 和 反向代理 服務(wù)器，也是一個(gè) IMAP/POP3/SMTP 代理服務(wù)器。 Nginx因穩(wěn)定性、豐富的功能集和低系統(tǒng)資源的消耗而聞名。

從中我們可以看出，nginx至少可以做web服務(wù)器，同時(shí)可以做反向代理服務(wù)器，同時(shí)又可以做郵件代理服務(wù)器，功能還是非常豐富的，稍后我們會(huì)對(duì)nginx的功能模塊做簡(jiǎn)要的介紹。

作為web服務(wù)器，nginx由于自身的優(yōu)勢(shì)，在處理靜態(tài)文件上有著絕對(duì)的優(yōu)勢(shì)，所以也是天然的優(yōu)秀web服務(wù)器軟件。

什么是反向代理服務(wù)器，和我們平時(shí)說(shuō)的用代理服務(wù)器上國(guó)外網(wǎng)站又有什么區(qū)別？

有圖有真相，看圖說(shuō)話

代理服務(wù)器呢，就是當(dāng)我想訪問(wèn)某個(gè)網(wǎng)站的時(shí)候因?yàn)楦鞣N原因不能直接訪問(wèn)，我可以主動(dòng)或者被動(dòng)用一臺(tái)可以訪問(wèn)目標(biāo)站點(diǎn)的服務(wù)器做代理去訪問(wèn)我想要訪問(wèn)的站點(diǎn)。

當(dāng)我主動(dòng)去找代理服務(wù)器去訪問(wèn)是一種情況，還有一種比較悲催的情況，當(dāng)我們使用了某些無(wú)良寬帶運(yùn)營(yíng)商提供的物美價(jià)廉，縮水嚴(yán)重，還不斷搞各種潛規(guī)則的寬帶時(shí)候，就會(huì)碰到我們這些吃貨去訪問(wèn)點(diǎn)評(píng)網(wǎng)站的時(shí)候，首先是去訪問(wèn)寬帶運(yùn)營(yíng)商局域網(wǎng)的代理服務(wù)器，然后代理服務(wù)器去訪問(wèn)點(diǎn)評(píng)的網(wǎng)站。這樣做對(duì)于寬帶運(yùn)營(yíng)商來(lái)說(shuō)，可以緩存一些數(shù)據(jù)，這樣就能節(jié)省點(diǎn)帶寬，但是對(duì)于我們這些使用寬帶的用戶而言，一則數(shù)據(jù)不安全，運(yùn)營(yíng)商的代理服務(wù)器上可能有我們的艷照也說(shuō)不定，二則，當(dāng)點(diǎn)評(píng)站點(diǎn)可正常訪問(wèn)，寬帶運(yùn)營(yíng)商代理服務(wù)器出現(xiàn)問(wèn)題的時(shí)候，就會(huì)收到各種用戶投訴，點(diǎn)評(píng)又跪了，這讓吃貨怎么活？問(wèn)題是點(diǎn)評(píng)活的好好的，用戶卻訪問(wèn)不到。

反向代理（Reverse Proxy）是指以代理服務(wù)器來(lái)接受internet上的連接請(qǐng)求，然后將請(qǐng)求轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡(luò)上的服務(wù)器，并將從服務(wù)器上得到的結(jié)果返回給internet上請(qǐng)求連接的客戶端，此時(shí)代理服務(wù)器對(duì)外就表現(xiàn)為一個(gè)服務(wù)器。

反向代理服務(wù)器可以看下面圖，nginx就是反向代理的角色，用戶的請(qǐng)求是先發(fā)到nginx，然后轉(zhuǎn)發(fā)到后端的tomcat。

當(dāng)然，代理服務(wù)器和反向代理服務(wù)器的類型不只web服務(wù)一種。

如下是一個(gè)簡(jiǎn)單的反向代理的配置：

server_name qunying.dianping.com;  
location / {  
proxy_pass test.qunying.liu.dianping.com; //反向代理站。  
index index.html index.htm;  
} 

當(dāng)用戶訪問(wèn)qunying.dianping.com/helloword.jsp的時(shí)候，這臺(tái)服務(wù)器上的nginx就會(huì)將用戶的請(qǐng)求轉(zhuǎn)發(fā)到qunying.liu.dianping.com/helloword.jsp,當(dāng)然proxy_pass轉(zhuǎn)向的地址也可以是內(nèi)部地址，比如127.0.0.1：8080

當(dāng)然對(duì)于我們線上的環(huán)境，nginx不是作為典型的反向代理在使用，目前點(diǎn)評(píng)java相關(guān)web業(yè)務(wù)服務(wù)器上采用的是 nginx （緩存和壓縮，日志）+tomcat（java容器），充分利用了nginx低系統(tǒng)占用以及高并發(fā)處理的優(yōu)勢(shì)。

很多人會(huì)有疑問(wèn)，tomcat也可以做web容器的啊，改個(gè)端口不就可以直接給用戶提供服務(wù)了，而且tomcat也能記錄日志，沒(méi)必要再放一個(gè)nginx啊。

tomcat 前面有沒(méi)有必要放一個(gè)nginx呢？

術(shù)業(yè)有專攻，tomcat做web服務(wù)器是兼職，做java容器是專職。nginx服務(wù)器是專職做web服務(wù)器，支持高并發(fā)，響應(yīng)快，擅長(zhǎng)處理靜態(tài)內(nèi)容，而且可以把動(dòng)態(tài)內(nèi)容交給tomcat處理。用tomcat做web容器響應(yīng)用戶請(qǐng)求，有可能1分鐘只能處理10個(gè)請(qǐng)求，但是用nginx+tomcat一分鐘就可能可以處理100個(gè)請(qǐng)求。

nginx為什么可以這么快處理用戶的請(qǐng)求呢？

nginx的進(jìn)程模型以及系統(tǒng)事件機(jī)制

nginx啟動(dòng)后的進(jìn)程，如圖所示：

我們可以看到master進(jìn)程，是以root身份啟動(dòng)，執(zhí)行內(nèi)容為：/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf

worker進(jìn)程都是以我們指定的nobody身份運(yùn)行，其中有一個(gè)worker進(jìn)程是舊的worker進(jìn)程奔潰后，自動(dòng)重新創(chuàng)建的，你能找到他嗎？

nginx在啟動(dòng)后，會(huì)有一個(gè)master進(jìn)程和多個(gè)worker進(jìn)程。master進(jìn)程主要用來(lái)管理worker進(jìn)程，包含：接收來(lái)自外界的信號(hào)，向各個(gè)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(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，只需要通過(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)新的進(jìn)程，并向所有老的進(jìn)程發(fā)送信號(hào)，告訴他們可以光榮退休了。新的進(jìn)程在啟動(dòng)后，就開(kāi)始接收新的請(qǐng)求，而老的進(jìn)程在收到來(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)一樣了。

#p#

worker進(jìn)程是如何處理我們的http請(qǐng)求的？

master（master進(jìn)程會(huì)先建立好需要listen的socket）--------fork生成子進(jìn)程workers，繼承socket（此時(shí)workers子進(jìn)程們都繼承了父進(jìn)程master的所有屬性，當(dāng)然也包括已經(jīng)建立好的socket，當(dāng)然不是同一個(gè)socket，只是每個(gè)進(jìn)程的這個(gè)socket會(huì)監(jiān)控在同一個(gè)ip地址與端口，這個(gè)在網(wǎng)絡(luò)協(xié)議里面是允許的）------當(dāng)一個(gè)連接進(jìn)入，產(chǎn)生驚群現(xiàn)象（驚群現(xiàn)象：指一個(gè)fd的事件被觸發(fā)后，等候這個(gè)fd的所有線程/進(jìn)程都被喚醒。雖然都被喚醒，但是只有一個(gè)會(huì)去響應(yīng)。）。

Nginx對(duì)驚群現(xiàn)象的處理：共享鎖

nginx提供了一個(gè)accept_mutex這個(gè)東西，從名字上，我們可以看這是一個(gè)加在accept上的一把共享鎖。有了這把鎖之后，同一時(shí)刻，就只會(huì)有一個(gè)進(jìn)程在accpet連接，這樣就不會(huì)有驚群?jiǎn)栴}了。accept_mutex是一個(gè)可控選項(xiàng)，我們可以顯示地關(guān)掉，默認(rèn)是打開(kāi)的。

worker進(jìn)程工作：

當(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)程中處理。

采用這種方式的好處：

1）節(jié)省鎖帶來(lái)的開(kāi)銷。對(duì)于每個(gè)worker進(jìn)程來(lái)說(shuō)，獨(dú)立的進(jìn)程，不需要加鎖，所以省掉了鎖帶來(lái)的開(kāi)銷，同時(shí)在編程以及問(wèn)題查上時(shí)，也會(huì)方便很多

2）獨(dú)立進(jìn)程，減少風(fēng)險(xiǎn)。采用獨(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的事件處理機(jī)制，采用異步非阻塞事件處理機(jī)制，一個(gè)worker進(jìn)程只有一個(gè)主線程，通過(guò)異步非阻塞的事件處理機(jī)制，實(shí)現(xiàn)了循環(huán)處理多個(gè)準(zhǔn)備好的事件，從而實(shí)現(xiàn)輕量級(jí)和高并發(fā)。

異步非阻塞事件處理機(jī)制：

同步和異步的概念,這兩個(gè)概念與消息的通知機(jī)制有關(guān).同步的情況下,是由處理消息者自己去等待消息是否被觸發(fā),而異步的情況下是由觸發(fā)機(jī)制來(lái)通知處理消息者。

阻塞和非阻塞,這兩個(gè)概念與程序等待消息(無(wú)所謂同步或者異步)時(shí)的狀態(tài)有關(guān).

當(dāng)讀寫(xiě)事件沒(méi)有準(zhǔn)備好時(shí)，就放入epoll里面。如果有事件準(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)備好的事件。

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

之前我們提到nginx的負(fù)載均衡功能，那么和LVS的負(fù)載均衡有什么區(qū)別呢？

負(fù)載均衡分為：

L4 switch（四層交換），即在OSI第4層工作，就是TCP層啦。此種Load Balance不理解應(yīng)用協(xié)議（如HTTP/FTP/MySQL等等）。例子：LVS，F(xiàn)5

L7 switch（七層交換），OSI的***層，應(yīng)用層。此時(shí)，該Load Balancer能理解應(yīng)用協(xié)議。例子：haproxy，MySQL Proxy

很多Load Balancer（例如F5）既可以做四層交換，也可以做七層交換。

LVS 工作在網(wǎng)絡(luò)4層僅做請(qǐng)求分發(fā)之用沒(méi)有流量，可配置性低，幾乎可對(duì)所有應(yīng)用做負(fù)載均衡，對(duì)網(wǎng)絡(luò)依賴大，沒(méi)有健康檢查機(jī)制。

nginx的7層(應(yīng)用層)，所以它可以針對(duì)http應(yīng)用本身來(lái)做分流策略，比如針對(duì)域名、目錄結(jié)構(gòu)等，對(duì)網(wǎng)絡(luò)依賴小，可檢測(cè)服務(wù)器內(nèi)部錯(cuò)誤。
 

nginx可以根據(jù)URL進(jìn)行負(fù)載均衡的請(qǐng)求轉(zhuǎn)發(fā)，而LVS只能根據(jù)ip:port進(jìn)行請(qǐng)求轉(zhuǎn)發(fā)

一般情況下，LVS會(huì)被放在最前端做負(fù)載均衡，nginx可作為lvs的節(jié)點(diǎn)服務(wù)器。

前面我們也提到過(guò)nginx實(shí)現(xiàn)郵件代理服務(wù)器的功能，一般使用nginx做郵件代理服務(wù)器的場(chǎng)景不多。

很不幸，nginx最早也是被當(dāng)作郵件代理服務(wù)器來(lái)開(kāi)發(fā)的。

--with-mail - 啟用 IMAP4/POP3/SMTP 代理模塊

安裝時(shí)需要注意的庫(kù)依賴：

• gzip模塊需要 zlib 庫(kù)
• rewrite模塊需要 pcre 庫(kù)
• ssl 功能需要openssl庫(kù)

我們nginx一般安裝在:/usr/local/nginx 目錄，nginx的安裝目錄結(jié)構(gòu)如下圖所示

/usr/local/nginx

├── conf（配置文件目錄）

│ ├── fastcgi.conf

│ ├── fastcgi.conf.default

│ ├── fastcgi_params

│ ├── fastcgi_params.default

│ ├── hosts

│ ├── koi-utf

│ ├── koi-win

│ ├── mime.types

│ ├── mime.types.default

│ ├── nginx_app.conf（應(yīng)用相關(guān)配置段 server段）

│ ├── nginx.conf（nginx公用配置信息 events，http段）

│ ├── nginx.conf.default

│ ├── nginx_status.conf

│ ├── proxy.conf

│ ├── scgi_params

│ ├── scgi_params.default

│ ├── uwsgi_params

│ ├── uwsgi_params.default

│ └── win-utf

├── html

│ ├── 50x.html

│ └── index.html

├── logs -> /data/applogs/nginx

├── sbin（nginx程序目錄）

│ └── nginx

└── tmpdir

├── client_body_temp

├── fastcgi_temp

├── proxy_temp

│ ├── 0

│ │ └── 01

│ ├── 1

│ │ ├── 00

│ │ └── 01

│ ├── 2

│ │ ├── 00

│ │ └── 01

│ ├── 3

│ │ ├── 00

│ │ └── 01

│ ├── 4

│ │ ├── 00

│ │ └── 01

│ ├── 5

│ │ ├── 00

│ │ └── 01

│ ├── 6

│ │ ├── 00

│ │ └── 01

│ ├── 7

│ │ ├── 00

│ │ └── 01

│ ├── 8

│ │ ├── 00

│ │ └── 01

│ └── 9

│ └── 00

├── scgi_temp

└── uwsgi_temp

#p#

nginx基本配置文件：

#運(yùn)行用戶（worker進(jìn)程屬主）
user nobody;
#啟動(dòng)進(jìn)程,設(shè)置成和cpu的數(shù)量相等

worker_processes 4;  
#全局錯(cuò)誤日志及PID文件  
#error_log logs/error.log;  
#error_log logs/error.log notice;  
#error_log logs/error.log info;  
#pid logs/nginx.pid;  
#工作模式及連接數(shù)上限  
events {  
#epoll是多路復(fù)用IO(I/O Multiplexing)中的一種方式,  
#僅用于linux2.6以上內(nèi)核,可以大大提高nginx的性能  
use epoll;  
#單個(gè)后臺(tái)worker process進(jìn)程的***并發(fā)鏈接數(shù)   
worker_connections 1024;  
# 并發(fā)總數(shù)是 worker_processes 和 worker_connections 的乘積  
# 即 max_clients = worker_processes * worker_connections  
# worker_connections 值的設(shè)置跟物理內(nèi)存大小有關(guān)  
# 因?yàn)椴l(fā)受IO約束，max_clients的值須小于系統(tǒng)可以打開(kāi)的***文件數(shù)  
# 系統(tǒng)可以打開(kāi)的***文件數(shù)和內(nèi)存大小成正比  
# $ cat /proc/sys/fs/file-max  
# 并發(fā)連接總數(shù)小于系統(tǒng)可以打開(kāi)的文件句柄總數(shù)，這樣就在操作系統(tǒng)可以承受的范圍之內(nèi)  
# worker_connections 的值需根據(jù) worker_processes 進(jìn)程數(shù)目和系統(tǒng)可以打開(kāi)的***文件總數(shù)進(jìn)行適當(dāng)?shù)剡M(jìn)行設(shè)置  
# 根據(jù)主機(jī)的物理可用CPU和可用內(nèi)存進(jìn)行配置  
}  
http {  
#設(shè)定mime類型,類型由mime.type文件定義  
include mime.types;  
default_type application/octet-stream;  
#設(shè)定日志格式  
log_format main '$remote_addr - $remote_user [$time_local] "$request" '  
'$status $body_bytes_sent "$http_referer" '  
'"$http_user_agent" "$http_x_forwarded_for"';  
access_log logs/access.log main;  
#sendfile 指令指定 nginx 是否調(diào)用 sendfile 函數(shù)（zero copy 方式）來(lái)輸出文件，  
#對(duì)于普通應(yīng)用，必須設(shè)為 on,  
#如果用來(lái)進(jìn)行下載等應(yīng)用磁盤(pán)IO重負(fù)載應(yīng)用，可設(shè)置為 off，以平衡磁盤(pán)與網(wǎng)絡(luò)I/O處理速度，降低系統(tǒng)的uptime.  
sendfile on;  
#tcp_nopush on;  
#連接超時(shí)時(shí)間  
#keepalive_timeout 0;  
keepalive_timeout 65;  
tcp_nodelay on;  
#開(kāi)啟gzip壓縮  
gzip on;  
gzip_disable "MSIE [1-6].";  
#設(shè)定請(qǐng)求緩沖  
client_header_buffer_size 128k;  
large_client_header_buffers 4 128k;  
#設(shè)定虛擬主機(jī)配置  
server {  
#偵聽(tīng)80端口  
listen 80;  
#定義使用 www.nginx.cn訪問(wèn)  
server_name www.nginx.cn;  
#定義服務(wù)器的默認(rèn)網(wǎng)站根目錄位置  
root html;  
#設(shè)定本虛擬主機(jī)的訪問(wèn)日志  
access_log logs/nginx.access.log main;  
#默認(rèn)請(qǐng)求  
location / {  
#定義首頁(yè)索引文件的名稱  
index index.php index.html index.htm;   
}  
# 定義錯(cuò)誤提示頁(yè)面  
error_page 500 502 503 504 /50x.html;  
location = /50x.html {  
}  
#靜態(tài)文件，nginx自己處理  
location ~ ^/(images|javascript|js|css|flash|media|static)/ {  
#過(guò)期30天，靜態(tài)文件不怎么更新，過(guò)期可以設(shè)大一點(diǎn)，  
#如果頻繁更新，則可以設(shè)置得小一點(diǎn)。  
expires 30d;  
}  
#PHP 腳本請(qǐng)求全部轉(zhuǎn)發(fā)到 FastCGI處理. 使用FastCGI默認(rèn)配置.  
location ~ .php$ {  
fastcgi_pass 127.0.0.1:9000;  
fastcgi_index index.php;  
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;  
include fastcgi_params;  
}  
#禁止訪問(wèn) .htxxx 文件  
location ~ /.ht {  
deny all;  
}  
}  
} 

線上的一個(gè)應(yīng)用的配置文件：

user nobody nobody;  
worker_processes 4;  
worker_rlimit_nofile 51200;  
error_log logs/error.log notice;  
pid /var/run/nginx.pid;  
events {  
use epoll;  
worker_connections 51200;  
}  
http {  
server_tokens off;  
include mime.types;  
include proxy.conf;  
default_type application/octet-stream;  
charset utf-8;  
client_body_temp_path /usr/local/nginx/tmpdir/client_body_temp 1 2;  
proxy_temp_path /usr/local/nginx/tmpdir/proxy_temp 1 2;  
fastcgi_temp_path /usr/local/nginx/tmpdir/fastcgi_temp 1 2;  
uwsgi_temp_path /usr/local/nginx/tmpdir/uwsgi_temp 1 2;  
scgi_temp_path /usr/local/nginx/tmpdir/scgi_temp 1 2;  
ignore_invalid_headers on;  
server_names_hash_max_size 256;  
server_names_hash_bucket_size 64;  
client_header_buffer_size 8k;  
large_client_header_buffers 4 32k;  
connection_pool_size 256;  
request_pool_size 64k;  
output_buffers 2 128k;  
postpone_output 1460;  
client_header_timeout 1m;  
client_body_timeout 3m;  
send_timeout 3m;  
sendfile on;  
tcp_nodelay on;  
tcp_nopush off;  
reset_timedout_connection on;  
keepalive_timeout 20 5;  
keepalive_requests 100;  
gzip on;  
gzip_http_version 1.1;  
gzip_vary on;  
gzip_proxied any;  
gzip_min_length 1024;  
gzip_comp_level 6;  
gzip_buffers 16 8k;  
gzip_proxied expired no-cache no-store private auth no_last_modified no_etag;  
gzip_types text/plain application/x-javascript text/css application/xml application/json;  
gzip_disable "MSIE [1-6]\.(?!.*SV1)";  
include nginx_app.conf; #與應(yīng)用有關(guān)的server配置  
include nginx_status.conf; #單機(jī)nginx訪問(wèn)統(tǒng)計(jì)配置 

Nginx配置文件分為好多塊，常見(jiàn)的從外到內(nèi)依次是「http」、「server」、「location」等等，缺省的繼承關(guān)系是從外到內(nèi)，也就是說(shuō)內(nèi)層塊會(huì)自動(dòng)獲取外層塊的值作為缺省值。

root和alias的區(qū)別

當(dāng)用戶訪問(wèn)http://ip:port/nginx/qunying/helloword.jsp時(shí)，nginx上可以進(jìn)行如下配置：

location /nginx/qunying/ {  
alias /home/qunying.liu/;  
}  

實(shí)際訪問(wèn)的文件是：/home/qunying.liu/helloword.jsp

或

location /nginx/qunying/ {  
root /home/;  
}  

實(shí)際訪問(wèn)的文件是：/home/qunying/helloword.jsp

在location /中配置root，在location /other中配置alias,推薦如此配置

nginx的目錄瀏覽功能：

在server里加上如下三行即可。

• autoindex on;
• autoindex_localtime on;
• autoindex_exact_size off;

nginx登錄驗(yàn)證：

在location段內(nèi)添加：

• auth_basic "phoenix slb admin ";
• auth_basic_user_file /data/appdatas/phoenix-slb-passwd;

***說(shuō)下：

nginx與tengine

官網(wǎng)介紹：http://tengine.taobao.org/

Tengine是由淘寶網(wǎng)發(fā)起的Web服務(wù)器項(xiàng)目。它在Nginx的基礎(chǔ)上，針對(duì)大訪問(wèn)量網(wǎng)站的需求，添加了很多高級(jí)功能和特性。Tengine的性能和穩(wěn)定性已經(jīng)在大型的網(wǎng)站如淘寶網(wǎng)，天貓商城等得到了很好的檢驗(yàn)。它的最終目標(biāo)是打造一個(gè)高效、穩(wěn)定、安全、易用的Web平臺(tái)。

我們的軟負(fù)載實(shí)際上是基于tengine 開(kāi)發(fā)的，個(gè)人認(rèn)為 tengine實(shí)際上就是nginx，只不過(guò)功能比nginx多，屬于Nginx的超集。

當(dāng)然，我們的科普之路才剛剛開(kāi)始，更多的還需要大家自行研究，快樂(lè)往往都是自找的。
 

書(shū)籍推薦：

《深入理解nginx:模塊開(kāi)發(fā)與架構(gòu)解析》 作者：陶輝 阿里巴巴資深nginx技術(shù)專家

參考資料：

http://blog.csdn.net/syhd142/article/details/8440667

http://blog.csdn.net/yankai0219/article/details/8018275

http://blog.csdn.net/yankai0219/article/details/8018232

http://www.cppblog.com/converse/archive/2009/05/13/82879.html

http://www.alidata.org/archives/1208

http://www.oschina.net/translate/nginx-setup

原文鏈接：http://mageedu.blog.51cto.com/4265610/1405190