Nginx (engine x) 是一個高性能的HTTP和反向代理web服務器,同時也提供了IMAP/POP3/SMTP服務。css
Nginx最大的特色是對高併發的支持和高效的負載均衡,在高併發的需求場景下,是Apache服務器不錯的替代品。html
1. 優勢前端
(1) 高併發量:根據官方給出的數據,可以支持高達 50,000 個併發鏈接數的響應。nginx
(2) 內存消耗少:處理靜態文件,一樣起web 服務,比apache 佔用更少的內存及資源,全部它是輕量級的。web
(3) 簡單穩定:配置簡單,基本在一個conf文件中配置,性能比較穩定,能夠7*24小時長時間不間斷運行。正則表達式
(4) 模塊化程度高:Nginx是高度模塊化的設計,編寫模塊相對簡單,包括 gzipping, byte ranges, chunked responses,以及 SSI-filter 等 filter,支持 SSL 和 TLSSNI。算法
(5) 支持Rwrite重寫規則:可以根據域名、URL的不一樣, 將HTTP請求分發到不一樣的後端服務器羣組。apache
(6) 低成本:Nginx能夠作高併發的負載均衡,且Nginx是開源免費的,若是使用F5等硬件來作負載均衡,硬件成本比較高。 後端
(7) 支持多系統:Nginx代碼徹底用C語言從頭寫成,已經移植到許多體系結構和操做系統,包括:Linux、FreeBSD、Solaris、Mac OS X、AIX以及Microsoft Windows,因爲Nginx是免費開源的,能夠在各系統上編譯並使用。緩存
2. 缺點
(1) 動態處理差:nginx處理靜態文件好,耗費內存少,可是處理動態頁面則很雞肋,如今通常前端用nginx做爲反向代理抗住壓力,apache做爲後端處理動態請求。
(2) rewrite弱:雖然nginx支持rewrite功能,可是相比於Apache來講,Apache比nginx 的rewrite 強大。
1. 正向代理
正向代理就是客戶端向代理髮送一個請求並指定目標(原始服務器),而後代理服務器向原始服務器轉交請求並將得到的內容返回給客戶端。
resolver 114.114.114.114 8.8.8.8; server { resolver_timeout 5s; listen 81; access_log e:/wwwrootproxy.access.log; error_log e:/wwwrootproxy.error.log; location / { proxy_pass http://$host$request_uri; } }
2. 反向代理
反向代理應該是Nginx作的最多的一件事了。反向代理就是:以代理服務器來接受internet上的鏈接請求,而後將請求轉發給內部網絡上的服務器,並將從服務器上獲得的結果返回給internet上請求鏈接的客戶端,此時代理服務器對外就表現爲一個反向代理服務器。簡單來講就是真實的服務器不能直接被外部網絡訪問,因此須要一臺代理服務器,而代理服務器能被外部網絡訪問的同時又跟真實服務器在同一個網絡環境,固然也多是同一臺服務器,端口不一樣而已。
一段簡單的實現反向代理的代碼:
server { listen 80; server_name localhost; client_max_body_size 1024M; location / { proxy_pass http://localhost:8080; proxy_set_header Host $host:$server_port; } }
保存配置文件後啓動Nginx,這樣當咱們訪問localhost的時候,就至關於訪問 localhost:8080 了。
3. HTTP服務器(包含動靜分離)
(1) Nginx自己也是一個靜態資源的服務器,當只有靜態資源的時候,就可使用Nginx來作服務器,同時如今也很流行動靜分離,就能夠經過Nginx來實現。
server { listen 80; server_name localhost; client_max_body_size 1024M; location / { root E:/wwwroot; index index.html; } }
這樣若是訪問 http://localhost 就會默認訪問到E
盤wwwroot
目錄下面的index.html
,若是一個網站只是靜態頁面的話,那麼就能夠經過這種方式來實現部署。
動靜分離是讓動態網站裏的動態網頁根據必定規則把不變的資源和常常變的資源區分開來,動靜資源作好了拆分之後,咱們就能夠根據靜態資源的特色將其作緩存操做,這就是網站靜態化處理的核心思路。
upstream test{ server localhost:8080; server localhost:8081; } server { listen 80; server_name localhost; location / { root e:/wwwroot; index index.html; } # 全部靜態請求都由nginx處理,存放目錄爲html location ~ .(gif|jpg|jpeg|png|bmp|swf|css|js)$ { root e:/wwwroot; } # 全部動態請求都轉發給tomcat處理 location ~ .(jsp|do)$ { proxy_pass http://test; } error_page 500 502 503 504 /50x.html; location = /50x.html { root e:/wwwroot; } }
這樣咱們就能夠把HTML以及圖片和css以及js放到wwwroot目錄下,而tomcat只負責處理jsp和請求,例如當咱們後綴爲gif的時候,Nginx默認會從wwwroot獲取到當前請求的動態圖文件返回,固然這裏的靜態文件跟Nginx是同一臺服務器,咱們也能夠在另一臺服務器,而後經過反向代理和負載均衡配置過去就行了,只要搞清楚了最基本的流程,不少配置就很簡單了,另外localtion後面實際上是一個正則表達式,因此很是靈活。
4. 負載均衡
負載均衡也是Nginx經常使用的一個功能,負載均衡其意思就是分攤到多個操做單元上進行執行,例如Web服務器、FTP服務器、企業關鍵應用服務器和其它關鍵任務服務器等,從而共同完成工做任務。簡單而言就是當有2臺或以上服務器時,根據規則隨機的將請求分發到指定的服務器上處理,負載均衡配置通常都須要同時配置反向代理,經過反向代理跳轉到負載均衡。而Nginx目前支持自帶3種負載均衡策略,還有2種經常使用的第三方策略。
(1) RR(默認)
每一個請求按時間順序逐一分配到不一樣的後端服務器,若是後端服務器down
掉,能自動剔除。
upstream test { server localhost:8080; server localhost:8081; } server { listen 81; server_name localhost; client_max_body_size 1024M; location / { proxy_pass http://test; proxy_set_header Host $host:$server_port; } } #負載均衡的核心代碼 upstream test { server localhost:8080; server localhost:8081; }
這裏配置了2臺服務器,固然其實是一臺,只是端口不同而已,而8081的服務器是不存在的,也就是說訪問不到,可是咱們訪問 http://localhost 的時候,也不會有問題,會默認跳轉到 http://localhost:8080 具體是由於Nginx會自動判斷服務器的狀態,若是服務器處於不能訪問(服務器掛了),就不會跳轉到這臺服務器,因此也避免了一臺服務器掛了影響使用的狀況,因爲Nginx默認是RR策略,因此咱們不須要其餘更多的設置。
(2) 權重
指定輪詢概率,weight和訪問比率成正比,用於後端服務器性能不均的狀況。 例如:
upstream test { server localhost:8080 weight=9; server localhost:8081 weight=1; }
那麼10
次通常只會有1
次會訪問到8081
,而有9
次會訪問到8080。
上面的2種方式都有一個問題,那就是下一個請求來的時候請求可能分發到另一個服務器,當咱們的程序不是無狀態的時候(採用了session保存數據),這時候就有一個很大的很問題了,好比把登陸信息保存到了session中,那麼跳轉到另一臺服務器的時候就須要從新登陸了,因此不少時候咱們須要一個客戶只訪問一個服務器,那麼就須要用iphash了,iphash的每一個請求按訪問ip的hash結果分配,這樣每一個訪客固定訪問一個後端服務器,能夠解決session的問題。
upstream test { ip_hash; server localhost:8080; server localhost:8081; }
(4) fair(第三方)
按後端服務器的響應時間來分配請求,響應時間短的優先分配。
upstream backend { fair; server localhost:8080; server localhost:8081; }
(5) url_hash(第三方)
按訪問url的hash結果來分配請求,使每一個url定向到同一個後端服務器,後端服務器爲緩存時比較有效。 在upstream中加入hash語句,server語句中不能寫入weight等其餘的參數,hash_method是使用的hash算法。
upstream backend { hash $request_uri; hash_method crc32; server localhost:8080; server localhost:8081; }
以上5種負載均衡各自適用不一樣狀況下使用,因此能夠根據實際狀況選擇使用哪一種策略模式,不過fair和url_hash須要安裝第三方模塊才能使用。