nginx 負載均衡分配

本節就聊聊採用Nginx負載均衡以後碰到的問題:nginx

  • Session問題數據庫

  • 文件上傳下載後端

一般解決服務器負載問題,都會經過多服務器分載來解決。常見的解決方案有:緩存

  • 網站入口經過分站連接負載(天空軟件站,華軍軟件園等)安全

  • DNS輪詢服務器

  • F5物理設備session

  • Nginx等輕量級架構架構

那咱們看看Nginx是如何實現負載均衡的,Nginx的upstream目前支持如下幾種方式的分配
一、輪詢(默認)
每一個請求按時間順序逐一分配到不一樣的後端服務器,若是後端服務器down掉,能自動剔除。
二、weight
指定輪詢概率,weight和訪問比率成正比,用於後端服務器性能不均的狀況。
二、ip_hash
每一個請求按訪問ip的hash結果分配,這樣每一個訪客固定訪問一個後端服務器,能夠解決session的問題。
三、fair(第三方)
按後端服務器的響應時間來分配請求,響應時間短的優先分配。
四、url_hash(第三方)
按訪問url的hash結果來分配請求,使每一個url定向到同一個後端服務器,後端服務器爲緩存時比較有效。負載均衡

Upstream配置如何實現負載   分佈式

複製代碼

http {    
   
   upstream  www.test1.com {
         ip_hash;
         server  
172.16.125.76:8066 weight=10;
         server  
172.16.125.76:8077 down;
         server  
172.16.0.18:8066 max_fails=3 fail_timeout=30s;
         server  
172.16.0.18:8077 backup;
    }
     
    upstream  www.test2.com {
         server  
172.16.0.21:8066;
         server  
192.168.76.98:8066;        
    }


    server {
       listen      
80;
       server_name  www.test1.com;        
     
       location
/{
          proxy_pass        http:
//www.test1.com;
          proxy_set_header   Host             $host;
          proxy_set_header   X
-Real-IP        $remote_addr;
          proxy_set_header   X
-Forwarded-For  $proxy_add_x_forwarded_for;
       }      
    }  
   
    server {
       listen      
80;
       server_name  www.test2.com;        
     
       location
/{
          proxy_pass        http:
//www.test2.com;
          proxy_set_header   Host             $host;
          proxy_set_header   X
-Real-IP        $remote_addr;
          proxy_set_header   X
-Forwarded-For  $proxy_add_x_forwarded_for;
    }
}

複製代碼

當有請求到www.test1.com/www.test2.com 時請求會被分發到對應的upstream設置的服務器列表上。test2的每一次請求分發的服務器都是隨機的,就是第一種狀況列舉的。而test1剛是根據來訪問ip的hashid來分發到指定的服務器,也就是說該IP的請求都是轉到這個指定的服務器上。

根據服務器的自己的性能差異及職能,能夠設置不一樣的參數控制。

down 表示負載太重或者不參與負載

weight 權重過大表明承擔的負載就越大

backup 其它服務器時或down時纔會請求backup服務器

max_fails 失敗超過指定次數會暫停或請求轉往其它服務器

fail_timeout 失敗超過指定次數後暫停時間

以上就Nginx的負載均衡的簡單配置。那繼續咱們的本節討論內容:

1、Session問題

當咱們肯定一系列負載的服務器後,那咱們的WEB站點會分佈到這些服務器上。這個時候若是採用Test2 每一次請求隨機訪問任何一臺服務器上,這樣致使你訪問A服務器後,下一次請求又忽然轉到B服務器上。這個時候與A服務器創建的Session,傳到B站點服務器確定是沒法正常響應的。咱們看一下經常使用的解決方案:

  • Session或憑據緩存到獨立的服務器

  • Session或憑據保存數據庫中

  • nginx ip_hash 保持同一IP的請求都是指定到固定的一臺服務器

第一種緩存的方式比較理想,緩存的效率也比較高。可是每一臺請求服務器都去訪問Session會話服務器,那不是加載重了這臺Session服務器的負擔嗎?

第二種保存到數據庫中,除了要控制Session的有效期,同時加劇了數據庫的負擔,因此最終的轉變爲SQL Server 負載均衡,涉及讀,寫,過時,同步。

第三種經過nginx ip_hash負載保持對同一服務器的會話,這種看起來最方便,最輕量。

正常狀況下架構簡單的話, ip_hash能夠解決Session問題,可是咱們來看看下面這種狀況

這個時候ip_hash 收到的請求都是來自固定IP代理的請求,若是代理IP的負載太高就會致使ip_hash對應的服務器負載壓力過大,這樣ip_hash就失去了負載均衡的做用了。

若是緩存能夠實現同步共享的話,咱們能夠經過多session服務器來解決單一負載太重的問題。那Memcached是否能夠作Session緩存服務器呢?MemcachedProvider提供了Session的功能,即將Session保存到數據庫中。那爲何不直接保存到數據庫中,而要經過Memcached保存到數據庫中呢?很簡單,若是直接保存到數據庫中,每一次請求Session有效性都要回數據庫驗證一下。其次,即便咱們爲數據庫創建一層緩存,那這個緩存也沒法實現分佈式共享,仍是針對同一臺緩存服務器負載太重。網上也看到有用Memcached實現Session緩存的成功案例,固然數據庫方式實現的仍是比較經常使用的,好比開源Disuz.net論壇。緩存實現的小範圍分佈式也是比較經常使用的,好比單點登陸也是一種特殊狀況。

2、文件上傳下載

若是實現了負載均衡,除了Session問題,咱們還會碰到文件的上傳下載問題。文件不可能上傳不一樣的服務器上,這樣會致使下載不到對應文件的問題。咱們看一下下面的方案

  • 獨立文件服務器 

  • 文件壓縮數據庫

兩種方案都是經常使用的,咱們來講一下文件壓縮數據庫,之前的方式都是將文件二進制壓縮相當系型數據庫,而如今NOSQL的流行,加上MongoDB處理文件又比較方便,因此文件壓庫又多了一種選擇。畢竟文件服務器的效率和管理以及安全都不及數據庫。

隨便聊聊這點事,其實也就是一些應用的趨勢和多一種解決方案的實現。

相關文章
相關標籤/搜索