NGINX負(fù)載均衡安裝配置手冊

1、概述Nginx介紹Nginx (engine x) 是一個高性能的 HTTP 和反向代理服務(wù)器，也是一個 IMAP/POP3/SMTP 代理服務(wù)器。 Nginx 是由 Igor Sysoev 為俄羅斯訪問量第二的 Rambler.ru 站點(diǎn)開發(fā)的，它已經(jīng)在該站點(diǎn)運(yùn)行超過三年了。Igor 將源代碼以類BSD許可證的形式發(fā)布。Nginx 超越 Apache 的高性能和穩(wěn)定性，使得國內(nèi)使用 Nginx 作為 Web 服務(wù)器的網(wǎng)站也越來越多，其中包括新浪博客、新浪播客、網(wǎng)易新聞、騰訊網(wǎng)、搜狐博客等門戶網(wǎng)站頻道，六間房、56.com等視頻分享網(wǎng)站，Discuz!官方論壇、水木社區(qū)等知名論壇，盛大在線、金

2、山逍遙網(wǎng)等網(wǎng)絡(luò)游戲網(wǎng)站，豆瓣、人人網(wǎng)、YUPOO相冊、金山愛詞霸、迅雷在線等新興Web 2.0網(wǎng)站。四層和七層負(fù)載均衡負(fù)載均衡設(shè)備也常被稱為四到七層交換機(jī)，那補(bǔ)充：所謂四層就是基于IP+端口的負(fù)載均衡；七層就是基于URL等應(yīng)用層信息的負(fù)載均衡；同理，還有基于MAC地址的二層負(fù)載均衡和基于IP地址的三層負(fù)載均衡。換句換說，二層負(fù)載均衡會通過一個虛擬MAC地址接收請求，然后再分配到真實(shí)的MAC地址；三層負(fù)載均衡會通過一個虛擬IP地址接收請求，然后再分配到真實(shí)的IP地址；四層通過虛擬IP+端口接收請求，然后再分配到真實(shí)的服務(wù)器；七層通過虛擬的URL或主機(jī)名接收請求，然后再分配到真實(shí)的服務(wù)器。所謂的四

3、到七層負(fù)載均衡，就是在對后臺的服務(wù)器進(jìn)行負(fù)載均衡時，依據(jù)四層的信息或七層的信息來決定怎么樣轉(zhuǎn)發(fā)流量。比如四層的負(fù)載均衡，就是通過發(fā)布三層的IP地址（VIP），然后加四層的端口號，來決定哪些流量需要做負(fù)載均衡，對需要處理的流量進(jìn)行NAT處理，轉(zhuǎn)發(fā)至后臺服務(wù)器，并記錄下這個TCP或者UDP的流量是由哪臺服務(wù)器處理的，后續(xù)這個連接的所有流量都同樣轉(zhuǎn)發(fā)到同一臺服務(wù)器處理。七層的負(fù)載均衡，就是在四層的基礎(chǔ)上（不能空中樓閣，沒有四層是絕對不可能有七層的），再考慮應(yīng)用層的特征，比如同一個WEB服務(wù)器的負(fù)載均衡，除了根據(jù)VIP加80端口辨別是否需要處理的流量，還可根據(jù)七層的URL、瀏覽器類別、語言來決定是否要

4、進(jìn)行負(fù)載均衡。舉個例子，如果你的web服務(wù)器分成兩組，一組是中文語言的，一組是英文語言的，那么七層負(fù)載均衡就可以當(dāng)用戶來訪問你的域名時，自動辨別用戶語言，然后選擇對應(yīng)的語言服務(wù)器組進(jìn)行負(fù)載均衡處理。四層和七層兩者到底區(qū)別在哪里？負(fù)載均衡器通常稱為四層交換機(jī)或七層交換機(jī)。四層交換機(jī)主要分析IP層及TCP/UDP層，實(shí)現(xiàn)四層流量負(fù)載均衡。七層交換機(jī)除了支持四層負(fù)載均衡以外，還有分析應(yīng)用層的信息，如HTTP協(xié)議URI或Cookie信息。1、負(fù)載均衡分為L4 switch（四層交換），即在OSI第4層工作，就是TCP層啦。此種Load Balance不理解應(yīng)用協(xié)議（如HTTP/FTP/MySQL等等）

5、。例子：LVS，F(xiàn)52、另一種叫做L7 switch（七層交換），OSI的最高層，應(yīng)用層。此時，該Load Balancer能理解應(yīng)用協(xié)議。例子：haproxy，MySQL Proxy注意：上面的很多Load Balancer既可以做四層交換，也可以做七層交換。如果單純要做HTTP的負(fù)載均衡，用haproxy好了。性能很強(qiáng)。另外，F(xiàn)5和Alteon這樣的硬件LB是LVS等軟件趕不上。 技術(shù)原理上的區(qū)別。所謂四層負(fù)載均衡，也就是主要通過報(bào)文中的目標(biāo)地址和端口，再加上負(fù)載均衡設(shè)備設(shè)置的服務(wù)器選擇方式，決定最終選擇的內(nèi)部服務(wù)器。以常見的TCP為例，負(fù)載均衡設(shè)備在接收到第一個來自客戶端的SYN 請求時

6、，即通過上述方式選擇一個最佳的服務(wù)器，并對報(bào)文中目標(biāo)IP地址進(jìn)行修改(改為后端服務(wù)器IP），直接轉(zhuǎn)發(fā)給該服務(wù)器。TCP的連接建立，即三次握手是客戶端和服務(wù)器直接建立的，負(fù)載均衡設(shè)備只是起到一個類似路由器的轉(zhuǎn)發(fā)動作。在某些部署情況下，為保證服務(wù)器回包可以正確返回給負(fù)載均衡設(shè)備，在轉(zhuǎn)發(fā)報(bào)文的同時可能還會對報(bào)文原來的源地址進(jìn)行修改。所謂七層負(fù)載均衡，也稱為“內(nèi)容交換”，也就是主要通過報(bào)文中的真正有意義的應(yīng)用層內(nèi)容，再加上負(fù)載均衡設(shè)備設(shè)置的服務(wù)器選擇方式，決定最終選擇的內(nèi)部服務(wù)器。以常見的TCP為例，負(fù)載均衡設(shè)備如果要根據(jù)真正的應(yīng)用層內(nèi)容再選擇服務(wù)器，只能先代理最終的服務(wù)器和客戶端建立連接(三次握手)

7、后，才可能接受到客戶端發(fā)送的真正應(yīng)用層內(nèi)容的報(bào)文，然后再根據(jù)該報(bào)文中的特定字段，再加上負(fù)載均衡設(shè)備設(shè)置的服務(wù)器選擇方式，決定最終選擇的內(nèi)部服務(wù)器。負(fù)載均衡設(shè)備在這種情況下，更類似于一個代理服務(wù)器。負(fù)載均衡和前端的客戶端以及后端的服務(wù)器會分別建立TCP連接。所以從這個技術(shù)原理上來看，七層負(fù)載均衡明顯的對負(fù)載均衡設(shè)備的要求更高，處理七層的能力也必然會低于四層模式的部署方式。 七層負(fù)載均衡應(yīng)用場景七層應(yīng)用負(fù)載的好處，是使得整個網(wǎng)絡(luò)更智能化, 參考我們之前的另外一篇專門針對HTTP應(yīng)用的優(yōu)化的介紹，就可以基本上了解這種方式的優(yōu)勢所在。例如訪問一個網(wǎng)站的用戶流量，可以通過七層的方式，將對圖片類的請求轉(zhuǎn)發(fā)

8、到特定的圖片服務(wù)器并可以使用緩存技術(shù)；將對文字類的請求可以轉(zhuǎn)發(fā)到特定的文字服務(wù)器并可以使用壓縮技術(shù)。當(dāng)然這只是七層應(yīng)用的一個小案例，從技術(shù)原理上，這種方式可以對客戶端的請求和服務(wù)器的響應(yīng)進(jìn)行任意意義上的修改，極大的提升了應(yīng)用系統(tǒng)在網(wǎng)絡(luò)層的靈活性。很多在后臺，(例如Nginx或者Apache)上部署的功能可以前移到負(fù)載均衡設(shè)備上，例如客戶請求中的Header重寫，服務(wù)器響應(yīng)中的關(guān)鍵字過濾或者內(nèi)容插入等功能。另外一個常常被提到功能就是安全性。網(wǎng)絡(luò)中最常見的SYN Flood攻擊，即黑客控制眾多源客戶端，使用虛假IP地址對同一目標(biāo)發(fā)送SYN攻擊，通常這種攻擊會大量發(fā)送SYN報(bào)文，耗盡服務(wù)器上的相關(guān)資

9、源，以達(dá)到Denial of Service(DoS)的目的。從技術(shù)原理上也可以看出，四層模式下這些SYN攻擊都會被轉(zhuǎn)發(fā)到后端的服務(wù)器上；而七層模式下這些SYN攻擊自然在負(fù)載均衡設(shè)備上就截止，不會影響后臺服務(wù)器的正常運(yùn)營。另外負(fù)載均衡設(shè)備可以在七層層面設(shè)定多種策略，過濾特定報(bào)文，例如SQL Injection等應(yīng)用層面的特定攻擊手段，從應(yīng)用層面進(jìn)一步提高系統(tǒng)整體安全?，F(xiàn)在的7層負(fù)載均衡，主要還是著重于應(yīng)用廣泛的HTTP協(xié)議，所以其應(yīng)用范圍主要是眾多的網(wǎng)站或者內(nèi)部信息平臺等基于B/S開發(fā)的系統(tǒng)。 4層負(fù)載均衡則對應(yīng)其他TCP應(yīng)用，例如基于C/S開發(fā)的ERP等系統(tǒng)。 七層應(yīng)用需要考慮的問題1：是否

10、真的必要，七層應(yīng)用的確可以提高流量智能化，同時必不可免的帶來設(shè)備配置復(fù)雜，負(fù)載均衡壓力增高以及故障排查上的復(fù)雜性等問題。在設(shè)計(jì)系統(tǒng)時需要考慮四層七層同時應(yīng)用的混雜情況。2：是否真的可以提高安全性。例如SYN Flood攻擊，七層模式的確將這些流量從服務(wù)器屏蔽，但負(fù)載均衡設(shè)備本身要有強(qiáng)大的抗DDoS能力，否則即使服務(wù)器正常而作為中樞調(diào)度的負(fù)載均衡設(shè)備故障也會導(dǎo)致整個應(yīng)用的崩潰。3：是否有足夠的靈活度。七層應(yīng)用的優(yōu)勢是可以讓整個應(yīng)用的流量智能化，但是負(fù)載均衡設(shè)備需要提供完善的七層功能，滿足客戶根據(jù)不同情況的基于應(yīng)用的調(diào)度。最簡單的一個考核就是能否取代后臺Nginx或者Apache等服務(wù)器上的調(diào)度功

11、能。能夠提供一個七層應(yīng)用開發(fā)接口的負(fù)載均衡設(shè)備，可以讓客戶根據(jù)需求任意設(shè)定功能，才真正有可能提供強(qiáng)大的靈活性和智能性。Nginx做七層負(fù)載均衡的優(yōu)點(diǎn)1、高并發(fā)連接：官方測試能夠支撐5萬并發(fā)連接，在實(shí)際生產(chǎn)環(huán)境中跑到23萬并發(fā)連接數(shù)。2、內(nèi)存消耗少：在3萬并發(fā)連接下，開啟的10個Nginx 進(jìn)程才消耗150M內(nèi)存（15M*10=150M）。3、配置文件非常簡單：風(fēng)格跟程序一樣通俗易懂。4、成本低廉：Nginx為開源軟件，可以免費(fèi)使用。而購買F5 BIG-IP、NetScaler等硬件負(fù)載均衡交換機(jī)則需要十多萬至幾十萬人民幣。5、支持Rewrite重寫規(guī)則：能夠根據(jù)域名、URL的不同，將 HTTP

12、 請求分到不同的后端服務(wù)器群組。6、內(nèi)置的健康檢查功能：如果 Nginx Proxy 后端的某臺 Web 服務(wù)器宕機(jī)了，不會影響前端訪問。7、節(jié)省帶寬：支持 GZIP 壓縮，可以添加瀏覽器本地緩存的 Header 頭。8、穩(wěn)定性高：用于反向代理，宕機(jī)的概率微乎其微。9、支持熱部署：不間斷服務(wù)進(jìn)行更新。Nginx原理Nginx的負(fù)載均衡是一個基于內(nèi)容和應(yīng)用的七層交換負(fù)載均衡的實(shí)現(xiàn)。同樣Nginx也是一個Http的服務(wù)端。nginx配置負(fù)載均衡工作在TCP/IP協(xié)議的第七層，即應(yīng)用層，屬于七層負(fù)載均衡。 七層負(fù)載均衡的優(yōu)勢1.通過對HTTP報(bào)頭的檢查，可以檢測出HTTP400、500和600系列的

13、錯誤信息，因而能透明地將連接請求重新定向到另一臺服務(wù)器，避免應(yīng)用層故障。2.可根據(jù)流經(jīng)的數(shù)據(jù)類型（如判斷數(shù)據(jù)包是圖像文件、壓縮文件或多媒體文件格式等），把數(shù)據(jù)流量引向相應(yīng)內(nèi)容的服務(wù)器來處理，增加系統(tǒng)性能。3.能根據(jù)連接請求的類型，如是普通文本、圖象等靜態(tài)文檔請求，還是asp、cgi等的動態(tài)文檔請求，把相應(yīng)的請求引向相應(yīng)的服務(wù)器來處理，提高系統(tǒng)的性能及安全性。 Nginx并發(fā)能力強(qiáng)的原因在業(yè)界，一直流傳這樣一句話：Nginx抗并發(fā)能力強(qiáng)！為什么Nginx抗并發(fā)能力強(qiáng)？原因是使用了非阻塞、異步傳輸阻塞：如apache代理tomcat時，apache開啟10個進(jìn)程，同時處理著10個請求，在tomca

14、t沒有返回給apache結(jié)果時，apache是不會處理用戶發(fā)出的第11個請求非阻塞：如nginx代理tomcat時，nginx開啟1000個并發(fā)，同時處理著1000個請求，在tomcat沒有返回給nginx結(jié)果時，nginx會依然處理后面用戶發(fā)給的請求同步傳輸：比如squid代理tomcat時，瀏覽器發(fā)起請求，然后請求會squid立刻被轉(zhuǎn)到后端服務(wù)器，于是在瀏覽器和后端服務(wù)器之間就建立了一個連接。在請求發(fā)起到請求完成，這條連接都是一直存在的。異步傳輸：比如nginx代理tomcat時，瀏覽器發(fā)起請求，請求不會立刻轉(zhuǎn)到后端服務(wù)器，而是將請求數(shù)據(jù)（header）先保存到nginx上，然后nginx

15、再把這個請求發(fā)到后端服務(wù)器， 后端服務(wù)器處理完之后把數(shù)據(jù)返回到nginx上，nginx將數(shù)據(jù)流發(fā)到瀏覽器。假設(shè)用戶執(zhí)行一個上傳文件操作，由于用戶網(wǎng)速較慢，因此需要花半個小時才能把文件傳到服務(wù)器。squid的同步代理在用戶開始上傳后就和后端tomcat建立了連接，半小時后文件上傳結(jié)束，所以，后端tomcat服務(wù)器連接保持了半個小時；而nginx異步代理就是先將數(shù)據(jù)保存在nginx上，因此僅僅是nginx和用戶 保持了半小時連接，后端服務(wù)器在這半小時內(nèi)沒有為這個請求開啟連接，半小時后用戶上傳結(jié)束，nginx才將上傳內(nèi)容發(fā)到后端tomcat，nginx和后臺之間的帶寬 是很充裕的，所以只花了一秒鐘就

16、將請求發(fā)送到了后臺，由此可見，后端服務(wù)器連接保持了一秒。 Nginx負(fù)載均衡模塊(upstream)nginx配置負(fù)載均衡使用的模塊是ngx_http_upstream_module，這個模塊默認(rèn)安裝，因此不用在編譯nginx時做過多配置。相關(guān)指令有upstream、server、ip hash、keepalive等。Upstream模塊是Nginx 負(fù)載均衡的主要模塊，它提供了簡單的辦法來實(shí)現(xiàn)在輪詢和客戶端IP之間的后端服務(wù)器負(fù)載均衡,并可以對服務(wù)器進(jìn)行健康檢查。upstream并不處理請求，而是通過請求后端服務(wù)器得到用戶的請求內(nèi)容。在轉(zhuǎn)發(fā)給后端時，默認(rèn)是輪詢，也可以是ip_hash。具體配

17、置參數(shù)可以參考nginx配置負(fù)載均衡詳解這篇文章/2012/nginx_offical_doc_0628/202.html或者官方文檔/en/docs/http/ngx_http_upstream_module.html 代理模塊（proxy）Proxy為Nginx的代理模塊，允許將用戶的HTTP請求轉(zhuǎn)發(fā)到后端服務(wù)器，同時也可以結(jié)合upstream模塊，達(dá)到負(fù)載均衡的目的。注：proxy相關(guān)功能、指令很多，在此只講與upstream相關(guān)的指令和功能proxy模塊常用指令解釋：proxy_pass：指定轉(zhuǎn)發(fā)到后端服務(wù)器的請求

18、，在location中指定，常用URI類型如下TCP套接字：proxy_pass :8080;Unix套接字：proxy_pass http:/unix:/tmp/nginx.sock;Upstream區(qū)段：proxy_pass http:/nginx_pool;域名：proxy_pass ; 健康檢查Nginx的健康檢查主要體現(xiàn)在對后端服務(wù)提供健康檢查，且功能被集成在upstream模塊中，共有兩個指令max_fails:定義定義可以發(fā)生錯誤的最大次數(shù)fail_timeout：nginx在fail_timeout設(shè)定的時間內(nèi)與后端服

19、務(wù)器通信失敗的次數(shù)超過max_fails設(shè)定的次數(shù)，則認(rèn)為這個服務(wù)器不在起作用；在接下來的 fail_timeout時間內(nèi)，nginx不再將請求分發(fā)給失效的server。健康檢查機(jī)制：Nginx在檢測到后端服務(wù)器故障后，nginx依然會把請求轉(zhuǎn)向該服務(wù)器，當(dāng)nginx發(fā)現(xiàn)timeout或者refused后，會把改請求會分發(fā)到upstream的其它節(jié)點(diǎn)，直到獲得正常數(shù)據(jù)后，nginx才會把數(shù)據(jù)返回給用戶，這也便體現(xiàn)了nginx的異步傳輸，而lvs/haproxy/apache責(zé)無法做到這些（在lvs/haproxy/apache里，每個請求都只有一次機(jī)會，假如用戶發(fā)起一個請求，結(jié)果該請求分到的后

20、端服務(wù)器剛好掛掉了，那么這個請求就失敗了）使用nginx做為負(fù)載均衡器時，通訊模型類似于LVS-NAT，在某些情況下，隨著集群節(jié)點(diǎn)數(shù)量的增長，nginx將會成為網(wǎng)絡(luò)通訊的瓶頸，因?yàn)樗袘?yīng)答數(shù)據(jù)包都必須通過nginx，一顆400MHz的處理器能夠容納100Mbps的連接，因此，在一般情況下，網(wǎng)絡(luò)更可能比LVS Director更可能成為瓶頸。在這種情況下，使用LVS-DR比使用nginx做負(fù)載均衡器上更可靠一些。反向代理（Reverse Proxy）方式是指以代理服務(wù)器來接受internet上的連接請求，然后將請求轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡(luò)上的服務(wù)器，并將從服務(wù)器上得到的結(jié)果返回給internet上請求連接

21、的客戶端，此時代理服務(wù)器對外就表現(xiàn)為一個服務(wù)器。負(fù)載均衡，英文名稱為Load Balance，其意思就是將負(fù)載（工作任務(wù)）進(jìn)行平衡、分?jǐn)偟蕉鄠€操作單元上進(jìn)行執(zhí)行，例如Web服務(wù)器、FTP服務(wù)器、企業(yè)關(guān)鍵應(yīng)用服務(wù)器和其它關(guān)鍵任務(wù)服務(wù)器等，從而共同完成工作任務(wù)。Nginx負(fù)載均衡調(diào)度策略nginx的upstream目前支持以下幾種方式的分配：1、輪詢（默認(rèn)）每個請求按時間順序逐一分配到不同的后端服務(wù)器，如果后端服務(wù)器down掉，能自動剔除。2、weight指定輪詢幾率，weight和訪問比率成正比，用于后端服務(wù)器性能不均的情況。好的服務(wù)器weight高些，差的服務(wù)器weight低些。例如：upst

22、ream bakend server 4 weight=10;server 5 weight=10;3、ip_hash每個請求按訪問ip的hash結(jié)果分配，這樣每個訪客固定訪問一個后端服務(wù)器，可以解決session的問題。無法將權(quán)重（weight）與ip_hash聯(lián)合使用來分發(fā)連接。如果有某臺服務(wù)器不可用，你必須標(biāo)記其為“down”。例如：upstream bakend ip_hash;server 4:88;server 5:80;4、fair（第三方）按后端服務(wù)器的響應(yīng)時間來分配請求，響應(yīng)時間短的優(yōu)先分

23、配。upstream backend server server1;server server2;fair;5、url_hash（第三方）按訪問url的hash結(jié)果來分配請求，使每個url定向到同一個后端服務(wù)器，后端服務(wù)器為緩存時比較有效。例：在upstream中加入hash語句，server語句中不能寫入weight等其他的參數(shù)，hash_method是使用的hash算法。upstream backend server squid1:3128;server squid2:3128;hash $request_uri;hash_method crc32;Session問題解決辦法：(1) ip

24、_hash(2) nginx-upstream-jvm-route (Nginx + tomcat )nginx中的ip_hash技術(shù)能夠?qū)⒛硞€ip的請求定向到同一臺后端，這樣一來這個ip下的某個客戶端和某個后端就能建立起穩(wěn)固的session，ip_hash是在upstream配置中定義的：upstream backend ip_hash; server :8001;server :8002;ip_hash是容易理解的，但是因?yàn)閮H僅能用ip這個因子來分配后端，因此ip_hash是有缺陷的，不能在一些情況下使用：1)nginx不是最前端的服務(wù)器。ip_hash

25、要求nginx一定是最前端的服務(wù)器，否則nginx得不到正確ip，就不能根據(jù)ip作hash。譬如使用 的是squid為最前端，那么nginx取ip時只能得到squid的服務(wù)器ip地址。2)nginx的后端還有其它方式的負(fù)載均衡。假如nginx后端又有其它負(fù)載均衡，將請求又通過另外的方式分流了，那么某個客戶端的請求不能定位到同一臺session應(yīng)用服務(wù)器上。模塊參數(shù)說明ngx_http_upstream_module/en/docs/http/ngx_http_upstream_module.htmlnginx負(fù)載均衡模塊：ngx_http_upstream_mod

26、ule配置例子指令 upstream server ip hash keepalive least connEmbedd Variablesnginx負(fù)載均衡模塊ngx_http_upstream_module允許定義一組服務(wù)器，這組服務(wù)器可以被proxy_pass，fastcgi_pass和memcached_pass這些指令引用。配置例子upstream backend server weight=5; server :8080; server unix:/tmp/backend3; server backu

27、:8080 backup; server :8080 backup;server location / proxy_pass http:/backend; 指令語法：upstream name .default：所屬指令：http定義一組用于實(shí)現(xiàn)nginx負(fù)載均衡的服務(wù)器，它們可以偵聽在不同的端口。另外，可以混合使用偵聽TCP與UNIX-domain套接字文件例子：upstream backend server weight=5; server :8080 max_fa

28、ils=3 fail_timeout=30s; server unix:/tmp/backend3;默認(rèn)情況下，請求被分散在使用加權(quán)輪詢的nginx負(fù)載均衡服務(wù)器上。在上面的例子中，每七個請求按下面分配：五個請求發(fā)送給，:8080和unix:/tmp/backend3各自分配一個。如果在于服務(wù)器通信時發(fā)生了一個錯誤，這個請求會被傳遞給下一個服務(wù)器，以此類推至道所有的功能服務(wù)器都嘗試過。如果不能從所有的這些nginx負(fù)載均衡服務(wù)器上獲得回應(yīng)，客戶端將會獲得最后一個鏈接的服務(wù)器的處理結(jié)果。語法：server 地址 參數(shù)；default：所屬

29、指令：upstream設(shè)置一個nginx負(fù)載均衡服務(wù)器的地址和其他參數(shù)。一個地址可以被指定為域名或IP地址，和一個可選的端口，或者被定為UNIX-domain套接字文件的路徑，使用unix:作為前綴。如果端口沒指定，則使用80端口。一個被解析到多個IP地址的域名本質(zhì)上指定了多個服務(wù)器。可以定義下面的參數(shù)：weight=number 設(shè)置服務(wù)器的權(quán)限，默認(rèn)是1max_fails=number 設(shè)置在fail_timeout參數(shù)設(shè)置的時間內(nèi)最大失敗次數(shù)，如果在這個時間內(nèi)，所有針對該服務(wù)器的請求都失敗了，那么認(rèn)為該服務(wù)器會被認(rèn)為是停機(jī)了，停機(jī)時間是fail_timeout設(shè)置的時間。默認(rèn)情況下，不成

30、功連接數(shù)被設(shè)置為1。被設(shè)置為零則表示不進(jìn)行鏈接數(shù)統(tǒng)計(jì)。哪里連接被認(rèn)為是不成功的可以通過proxy_next_upstream、fastcgi_next_upstream和memcached_next_upstream指令配置（http_404狀態(tài)不會被認(rèn)為是不成功的嘗試）。fail_timeout=time 設(shè)置多長時間內(nèi)失敗次數(shù)達(dá)到最大失敗次數(shù)會被認(rèn)為服務(wù)器停機(jī)了 服務(wù)器會被認(rèn)為停機(jī)的時間長度 默認(rèn)情況下，超時時間被設(shè)置為10Sfail_timeout與前端響應(yīng)時間沒有直接關(guān)系，不過可以使用proxy_connect_timeout和 proxy_read_timeout來控制。backup

31、 標(biāo)記該服務(wù)器為備用服務(wù)器。當(dāng)主服務(wù)器停止時，請求會被發(fā)送到它這里。down 標(biāo)記服務(wù)器永久停機(jī)了；與指令ip_hash一起使用。例子：upstream backend server weight=5; server :8080 max_fails=3 fail_timeout=30s; server unix:/tmp/backend3; server :8080 backup;語法：ip_hash;default:-所屬指令：upstream指定nginx負(fù)載均衡器組使用基于客戶端ip的負(fù)載均

32、衡算法。IPV4的前3個八進(jìn)制位和所有的IPV6地址被用作一個hash key。這個方法確保了相同客戶端的請求一直發(fā)送到相同的服務(wù)器上除非這個服務(wù)器被認(rèn)為是停機(jī)。這種情況下，請求會被發(fā)送到其他主機(jī)上，然后可能會一直發(fā)送到這個主機(jī)上。注意：在版本1.3.2中開始支持IPV6地址。如果nginx負(fù)載均衡器組里面的一個服務(wù)器要臨時移除，它應(yīng)該用參數(shù)down標(biāo)記，來防止之前的客戶端IP還往這個服務(wù)器上發(fā)請求。例子：upstream backend ip_hash; server ; server ; server back

33、 down; server ; 注意：在nginx版本1.3.1之前，不能在ip_hash中使用權(quán)重（weight）語法：keepalive 連接數(shù)；default：所屬模塊：upstream這個指令在版本1.1.4中出現(xiàn)nginx負(fù)載均衡器的活動鏈接數(shù)緩存。連接數(shù)（keepalive的值）指定了每個工作進(jìn)程中保留的持續(xù)連接到nginx負(fù)載均衡器緩存的最大值。如果超過這個設(shè)置值的閑置進(jìn)程想鏈接到nginx負(fù)載均衡器組，最先連接的將被關(guān)閉。應(yīng)該注意：keepalive指令不限制nginx工作進(jìn)程可以連接到nginx負(fù)載均衡器

34、可以開啟的最大公工作進(jìn)程，如果有需要的話，新進(jìn)程還是會被發(fā)起。連接數(shù)應(yīng)該被設(shè)置足夠低來滿足nginx負(fù)載均衡器處理新進(jìn)的連接。帶有持續(xù)連接（keepalive connections）的memcached upstream的配置例子upstream memcached_backend server :11211; server :11211; keepalive 32;server . location /memcached/ set $memcached_key $uri; memcached_pass memcached_backend; syntax:

35、least_conn;default: context: upstreamThis directive appeared in versions 1.3.1 and 1.2.2. Specifies that a group should use a load balancing method where a request is passed to the server with the least number of active connections, taking into account weights of servers. If there are several such s

36、ervers, they are tried using a weighted round-robin balancing method. nginx負(fù)載均衡器內(nèi)置變量（Embedded Variables）nginx負(fù)載均衡模塊ngx_http_upstream_module支持下列內(nèi)置變量：$upstream_addr保存一個服務(wù)器的IP地址和端口號或者UNIX-domain套接字文件的路徑。如果在處理請求過程中使用了多個服務(wù)器，那么它們的地址將以逗號分割，例如 ：“:80, :80, unix:/tmp/sock”。如果一個內(nèi)置的從一個服務(wù)器組

37、到另一個服務(wù)器組的重定向使用X-Accel-Redirect” or error_page ，那么那些服務(wù)器組以冒號隔開，例如“:80, :80, unix:/tmp/sock : :80, :80”。$upstream_response_time保存nginx負(fù)載均衡服務(wù)器響應(yīng)時間，以毫秒計(jì)。多個響應(yīng)也以逗號和冒號隔開。$upstream_status保存nginx負(fù)載均衡服務(wù)器響應(yīng)代碼。多個響應(yīng)代碼也以逗號或冒號隔開。$upstream_http_.保存nginx負(fù)載均衡服務(wù)器響應(yīng)頭字段。例如，th

38、e “Server” response header field is made available through the $upstream_http_server variable.注意，只有最后一個服務(wù)器響應(yīng)頭字段被保存。ngx_http_proxy_module/en/docs/http/ngx_http_proxy_module.htmlproxy_next_upstream語法： proxy_next_upstream error|timeout|invalid_header|http_500|http_502|http_503|http_504|h

39、ttp_404|off確定在何種情況下請求將轉(zhuǎn)發(fā)到下一個服務(wù)器。轉(zhuǎn)發(fā)請求只發(fā)生在沒有數(shù)據(jù)傳遞到客戶端的過程中。proxy_connect_timeout后端服務(wù)器連接的超時時間_發(fā)起握手等候響應(yīng)超時時間proxy_read_timeout連接成功后_等候后端服務(wù)器響應(yīng)時間_其實(shí)已經(jīng)進(jìn)入后端的排隊(duì)之中等候處理（也可以說是后端服務(wù)器處理請求的時間）proxy_send_timeout后端服務(wù)器數(shù)據(jù)回傳時間_就是在規(guī)定時間之內(nèi)后端服務(wù)器必須傳完所有的數(shù)據(jù)proxy_pass這個指令設(shè)置被代理服務(wù)器的地址和被映射的URI小技巧upstream bakend#定義負(fù)載均衡設(shè)備的Ip及設(shè)備 狀態(tài)ip_ha

40、sh;server :9090 down;server :8080 weight=2;server :6060;server :7070 backup;在需要使用負(fù)載均衡的server中增加proxy_pass http:/bakend/;每個設(shè)備的狀態(tài)設(shè)置為:1.down 表示單前的server暫時不參與負(fù)載2.weight 默認(rèn)為1.weight越大，負(fù)載的權(quán)重就越大。3.max_fails ：允許請求失敗的次數(shù)默認(rèn)為1.當(dāng)超過最大次數(shù)時，返proxy_next_upstream 模塊定義的錯誤4.fail_timeo

41、ut:max_fails次失敗后，暫停的時間。5.backup： 其它所有的非backup機(jī)器down或者忙的時候，請求backup機(jī)器。所以這臺機(jī)器壓力會最輕。nginx支持同時設(shè)置多組的負(fù)載均衡，用來給不用的server來使用。client_body_in_file_only 設(shè)置為On 可以講client post過來的數(shù)據(jù)記錄到文件中用來做debugclient_body_temp_path 設(shè)置記錄文件的目錄 可以設(shè)置最多3層目錄location 對URL進(jìn)行匹配.可以進(jìn)行重定向或者進(jìn)行新的代理、負(fù)載均衡Nginx典型應(yīng)用四層結(jié)構(gòu)：LVS負(fù)載均衡Nginx負(fù)載均衡內(nèi)容緩存Web服務(wù)器

42、安裝配置Nginx準(zhǔn)備工作 檢查openssl庫rpm -qa|grep openssl已安裝openssl和openssl-devel庫 檢查zlib庫rpm -qa|grep zlib已安裝zlib和zlib-devel庫 安裝pcre 6.6-6和pcre-devel 6.6-6 (REHL5.8 64bit)安裝pcre-7.8-4和pcre-devel-7.8-4 (RHEL6.3 64bit)（備注：一般情況下pcre已經(jīng)安裝，只需要安裝pcre-devel即可。）上傳以下文件至/tmp目錄：pcre-6.6-6.el5_6.1.x86_64.rpmpcre-devel-6.6-6

43、.el5_6.1.x86_64.rpmcd /tmprpm -Uvh pcre-6.6-6.el5_6.1.x86_64.rpmrpm -Uvh pcre-devel-6.6-6.el5_6.1.x86_64.rpm 修改打開文件數(shù)最大限制vi /etc/security/limits.conf在末尾添加以下內(nèi)容：* soft nofile * hard nofile 安裝Nginx 安裝nginx-1.4.1上傳nginx-1.4.1.tar.gz至/tmpcd /tmptar xzvf nginx-1.4.1.tar.gzcd /tmp/nginx-1.4.1sed -i s/Server

44、: nginx CRLF/Server: unkown CRLF/g src/http/ngx_http_header_filter_module.csed -i s/Server: NGINX_VER CRLF/Server: unkown CRLF/g src/http/ngx_http_header_filter_module.c./configure -prefix=/usr/local/nginx-1.4.1-lb -without-http_autoindex_module -without-http_ssi_module -without-mail_pop3_module -wi

45、thout-mail_imap_module -without-mail_smtp_module -without-http_fastcgi_module -without-http_scgi_module -with-http_stub_status_module -with-http_ssl_modulemakemake install 創(chuàng)建符號鏈接ln -s /usr/local/nginx-1.4.1-lb /usr/local/nginx-lb 刪除默認(rèn)html文件rm -rf /usr/local/nginx-lb/html/* 檢查/usr/local/nginx-lb/sbin

46、/nginx -v看命令是否輸出版本號配置Nginx 配置Nginx上傳nginx.conf文件至/usr/local/nginx-lb/conf目錄內(nèi)容如下：#user nobody;worker_processes 16;#error_log logs/error.log;#error_log logs/error.log notice;#error_log logs/error.log info;#pid logs/nginx.pid;#Specifies the value for maximum file descriptors that can be opened by this

47、process. limit by ulimit -nworker_rlimit_nofile ;events use epoll; worker_connections ;http include mime.types; default_type application/octet-stream; log_format main $remote_addr - $remote_user $time_local $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for; acces

48、s_log logs/access.log main; #server_names_hash_bucket_size 256; #client_header_buffer_size 256k; #large_client_header_buffers 4 256k; #允許客戶端請求的最大的單個文件字節(jié)數(shù) #client_max_body_size 50m; #緩沖區(qū)代理 緩沖用戶端請求的最大字節(jié)數(shù) 可以理解為先保存到本地再傳給用戶 #client_body_buffer_size 256k; #跟后端服務(wù)器連接的超時時間_發(fā)起握手等候響應(yīng)超時時間 #proxy_connect_timeout

49、 600; #連接成功后_等候后端服務(wù)器響應(yīng)時間_其實(shí)已經(jīng)進(jìn)入后端的排隊(duì)之中等候處理 #proxy_read_timeout 600; #后端服務(wù)器數(shù)據(jù)回傳時間_就是在規(guī)定時間之內(nèi)后端服務(wù)器必須傳完所有的數(shù)據(jù) #proxy_send_timeout 600; #代理請求緩存區(qū)_這個緩存區(qū)間會保存用戶的頭信息以供Nginx進(jìn)行規(guī)則處理_一般只要能保存下頭信息即可 #proxy_buffer_size 16k; #同上 告訴Nginx保存單個用的幾個Buffer 最大用多大空間 #proxy_buffers 4 64k; #如果系統(tǒng)很忙的時候可以申請更大的proxy_buffers 官方推薦*2 #proxy_busy_buffers_size 128k; #proxy緩存臨時文件的大小 #proxy_temp_file_write_size 128k; sendfile on; tcp_nopush on; keepalive_timeout 0; tcp_nodelay on; server_tokens off; #gzip on; #gzip_min_length 1k; #gzip_buffers 4 1024k; #gzip_http_version 1.1; #gzip_comp_level 2; #gzip_types tex