nginx反向代理 nginx.conf配製

Nginx是什麼？

由俄羅斯開發的反向代理服務器。Nginx 是Web服務器或反向代理服務器。

優勢：

 

• 跨平臺：Nginx 能夠在大多數 Unix like OS編譯運行，並且也有Windows的移植版本。
• 配置異常簡單：很是容易上手。配置風格跟程序開發同樣，神通常的配置
• 非阻塞、高併發鏈接：數據複製時，磁盤I/O的第一階段是非阻塞的。官方測試可以支撐5萬併發鏈接，在實際生產環境中跑到2～3萬併發鏈接數.(這得益於Nginx使用了最新的epoll模型)
• 事件驅動：通訊機制採用epoll模型，支持更大的併發鏈接。

 

特色：

• nginx代理和後端web服務器間無需長鏈接；
• 接收用戶請求是異步的，即先將用戶請求所有接收下來，再一次性發送後後端web服務器，極大的減輕後端web服務器的壓力
• 發送響應報文時，是邊接收來自後端web服務器的數據，邊發送給客戶端的
• 網絡依賴型低。NGINX對網絡的依賴程度很是低，理論上講，只要可以ping通就能夠實施負載均衡，並且能夠有效區份內網和外網流量

5、支持服務器檢測。NGINX可以根據應用服務器處理頁面返回的狀態碼、超時信息等檢測服務器是否出現故障，並及時返回錯誤的請求從新提交到其它節點上

經過一個實例瞭解nginx

假設有三臺服務器，一臺是nginx服務器，兩臺是tomcat服務器（至少兩臺）

服務器	地址	用途
Nginx	192.168.129.10	反向代理
Tomcat1	192.168.129.11	運行tomcat
Tomcat1	192.168.129.12	運行tomcat

當瀏覽器發送請求時，是經過nginx來訪問tomcat，得到數據後再由nginx傳給瀏覽器顯示。瀏覽器只能得到數據，不能知道是哪個tomcat把數據傳給他的，固然瀏覽器更是不想知道這些數據的，這樣保護了tomcat服務器上的資源安全，這就是反向代理

下圖是實際用戶經過nginx訪問數據，原始資源服務器被防火牆和nginx同時保護：

  

用戶A始終認爲它訪問的是原始服務器B而不是代理服務器Z，但實用際上反向代理服務器接受用戶A的應答，從原始資源服務器B中取得用戶A的需求資源，而後發送給用戶A。因爲防火牆的做用，只容許代理服務器Z訪問原始資源服務器B。儘管在這個虛擬的環境下，防火牆和反向代理的共同做用保護了原始資源服務器B，但用戶A並不知情。

實例步驟：

在linux環境下，在兩個tomcat1和tomcat2服務器下，啓動tomcat

-1.上傳tomcat的壓縮包，解壓到指定目錄

  tar zxvf apache-tomcat-7.0.68.tar.gz

-2.到解壓目錄找到批處理文件，開啓tomcat

  cd apache-tomcat-7.0.68

 ./bin/startup.sh

-3.能夠查看一下日誌文件，看是否成功

 tailf ./logs/catalina.out

修改nginx.conf

 vi /usr/local/nginx/conf/nginx.conf

 

在http節點下添加upstream（服務器集羣），server設置的是集羣服務器的信息，我這裏搭建了兩個站點，配置了兩條信息。

    #新加服務器集羣名稱爲Jq_one
    upstream localhost_jp{
 　　server  192.168.129.11:8080; 
 　　server  192.168.129.12:8080;
    }

 

    #在http節點下找到location節點修改

 

   location / {
            root  /home/ftpuser/www;
            index  index.html index.htm;

     #設置主機頭和客戶端真實地址，以便服務器獲取客戶端真實IP
     proxy_set_header   Host             $host;
     proxy_set_header   X-Real-IP        $remote_addr;
     proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;

     #鏈接超時時間

     proxy_connect_timeout 10;

     #發送超時時間
     proxy_send_timeout 10;

     #接收超時時間
     proxy_read_timeout 10;

     #反向代理配置
     proxy_pass http://localhost_jp;
 }

 

保存以後，你就能夠試一下訪問192.168.129.10，返回的頁面有多是tomcat1，有多是tomcat2中的數據

關於nginx選哪個tomcat服務器，是有五種負載均衡策略的，下面介紹一下：

-1.輪循
默認採用此策略，根據訪問的前後的時間，循環的訪問代理服務。

-2.Ip_hash
同一ip，始終訪問同一代理的服務。

upstream localhost_jp{

　　　ip_hash;
 　　server  192.168.129.11:8080; 
 　　server  192.168.129.12:8080;
   }
 
-3.權重
根據設置權重的值，自動計算百分比。

upstream localhost_jp{
 　　server  192.168.129.11:8080 weight=800; 
 　　server  192.168.129.12:8080 weight=200;
   }
 
-4.Fair
根據每一個地址響應的時間，分配資源。時間越短，越優先訪問。

-5.Url_hash
更具url地址計算hash值，同一url始終從同一服務器獲取內容，經常使用於cdn。

Nginx的內部(進程)模型

nginx是以多進程的方式來工做的，固然nginx也是支持多線程的方式的,只是咱們主流的方式仍是多進程的方式，也是nginx的默認方式。nginx採用多進程的方式有諸多好處 .

 (1) nginx在啓動後，會有一個master進程和多個worker進程。master進程主要用來管理worker進程，包含：接收來自外界的信號，向各worker進程發送信號，監控 worker進程的運行狀態,當worker進程退出後(異常狀況下)，會自動從新啓動新的worker進程。而基本的網絡事件，則是放在worker進程中來處理了 。多個worker進程之間是對等的，他們同等競爭來自客戶端的請求，各進程互相之間是獨立的 。一個請求，只可能在一個worker進程中處理，一個worker進程，不可能處理其它進程的請求。 worker進程的個數是能夠設置的，通常咱們會設置與機器cpu核數一致，這裏面的緣由與nginx的進程模型以及事件處理模型是分不開的 。

(2)Master接收到信號之後怎樣進行處理（./nginx -s reload ）?首先master進程在接到信號後，會先從新加載配置文件，而後再啓動新的進程，並向全部老的進程發送信號，告訴他們能夠光榮退休了。新的進程在啓動後，就開始接收新的請求，而老的進程在收到來自master的信號後，就再也不接收新的請求，而且在當前進程中的全部未處理完的請求處理完成後，再退出 .

(3) worker進程又是如何處理請求的呢？咱們前面有提到，worker進程之間是平等的，每一個進程，處理請求的機會也是同樣的。當咱們提供80端口的http服務時，一個鏈接請求過來，每一個進程都有可能處理這個鏈接，怎麼作到的呢？首先，每一個worker進程都是從master進程fork過來，在master進程裏面，先創建好須要listen的socket以後，而後再fork出多個worker進程，這樣每一個worker進程均可以去accept這個socket(固然不是同一個socket，只是每一個進程的這個socket會監控在同一個ip地址與端口，這個在網絡協議裏面是容許的)。通常來講，當一個鏈接進來後，全部在accept在這個socket上面的進程，都會收到通知，而只有一個進程能夠accept這個鏈接，其它的則accept失敗，這是所謂的驚羣現象。固然，nginx也不會視而不見，因此nginx提供了一個accept_mutex這個東西，從名字上，咱們能夠看這是一個加在accept上的一把共享鎖。有了這把鎖以後，同一時刻，就只會有一個進程在accpet鏈接，這樣就不會有驚羣問題了。accept_mutex是一個可控選項，咱們能夠顯示地關掉，默認是打開的。當一個worker進程在accept這個鏈接以後，就開始讀取請求，解析請求，處理請求，產生數據後，再返回給客戶端，最後才斷開鏈接，這樣一個完整的請求就是這樣的了。咱們能夠看到，一個請求，徹底由worker進程來處理，並且只在一個worker進程中處理。

(4):，nginx採用這種進程模型有什麼好處呢？採用獨立的進程，可讓互相之間不會影響，一個進程退出後，其它進程還在工做，服務不會中斷，master進程則很快從新啓動新的worker進程。固然，worker進程的異常退出，確定是程序有bug了，異常退出，會致使當前worker上的全部請求失敗，不過不會影響到全部請求，因此下降了風險。固然，好處還有不少，你們能夠慢慢體會。

(5).有人可能要問了，nginx採用多worker的方式來處理請求，每一個worker裏面只有一個主線程，那可以處理的併發數頗有限啊，多少個worker就能處理多少個併發，何來高併發呢？非也，這就是nginx的高明之處，nginx採用了異步非阻塞的方式來處理請求，也就是說，nginx是能夠同時處理成千上萬個請求的 .對於IIS服務器每一個請求會獨佔一個工做線程，當併發數上到幾千時，就同時有幾千的線程在處理請求了。這對操做系統來講，是個不小的挑戰，線程帶來的內存佔用很是大，線程的上下文切換帶來的cpu開銷很大，天然性能就上不去了，而這些開銷徹底是沒有意義的。咱們以前說過，推薦設置worker的個數爲cpu的核數，在這裏就很容易理解了，更多的worker數，只會致使進程來競爭cpu資源了，從而帶來沒必要要的上下文切換。並且，nginx爲了更好的利用多核特性，提供了cpu親緣性的綁定選項，咱們能夠將某一個進程綁定在某一個核上，這樣就不會由於進程的切換帶來cache的失效

 

Nginx常見配置說明

worker_processes 8;

#nginx進程數，建議設置爲等於CPU總核心數

worker_connections 65535;

#單個進程最大鏈接數（最大鏈接數=鏈接數*進程數）

client_header_buffer_size 32k; #上傳文件大小限制

large_client_header_buffers 4 64k; #設定請求緩

client_max_body_size 8m; #設定請求緩

autoindex on; #開啓目錄列表訪問，合適下載服務器，默認關閉。

tcp_nopush on; #防止網絡阻塞

tcp_nodelay on; #防止網絡阻塞

keepalive_timeout 120; #長鏈接超時時間，單位是秒

gzip on; #開啓gzip壓縮輸出

gzip_min_length 1k; #最小壓縮文件大小

gzip_buffers 4 16k; #壓縮緩衝區

gzip_http_version 1.0; #壓縮版本（默認1.1，前端若是是squid2.5請使用1.0）

gzip_comp_level 2; #壓縮等級

upstream blog.ha97.com {

#upstream的負載均衡，weight是權重，能夠根據機器配置定義權重。weigth參數表示權值，權值越高被分配到的概率越大。

server 192.168.80.121:80 weight=3;

server 192.168.80.122:80 weight=2;

server 192.168.80.123:80 weight=3;

}

#虛擬主機的配置

server

{

#監聽端口

listen 80;

#域名能夠有多個，用空格隔開

server_name www.ha97.com ha97.com;

index index.html index.htm index.php;

root /data/www/ha97;

location ~ .*.(php|php5)?$

{

fastcgi_pass 127.0.0.1:9000;

fastcgi_index index.php;

include fastcgi.conf;

}