nginx如何實現負載均衡分配

這篇文章將為大家詳細講解有關nginx如何實現負載均衡分配，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

采用Nginx負載均衡之后碰到的問題：

• Session問題

• 文件上傳下載

通常解決服務器負載問題，都會通過多服務器分載來解決。常見的解決方案有：

• 網站入口通過分站鏈接負載（天空軟件站，華軍軟件園等）

• DNS輪詢

• F5物理設備

• Nginx等輕量級架構

那我們看看Nginx是如何實現負載均衡的，Nginx的upstream目前支持以下幾種方式的分配
1、輪詢（默認）
每個請求按時間順序逐一分配到不同的后端服務器，如果后端服務器down掉，能自動剔除。
2、weight
指定輪詢幾率，weight和訪問比率成正比，用于后端服務器性能不均的情況。
2、ip_hash
每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問一個后端服務器，可以解決session的問題。
3、fair（第三方）
按后端服務器的響應時間來分配請求，響應時間短的優先分配。
4、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的負載均衡的簡單配置。那繼續我們的本節討論內容：

一、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論壇。緩存實現的小范圍分布式也是比較常用的，比如單點登錄也是一種特殊情況。

二、文件上傳下載

如果實現了負載均衡，除了Session問題，我們還會碰到文件的上傳下載問題。文件不可能上傳不同的服務器上，這樣會導致下載不到對應文件的問題。我們看一下下面的方案

• 獨立文件服務器 

• 文件壓縮數據庫

兩種方案都是常用的，我們來說一下文件壓縮數據庫，以前的方式都是將文件二進制壓縮至關系型數據庫，而現在NOSQL的流行，加上MongoDB處理文件又比較方便，所以文件壓庫又多了一種選擇。畢竟文件服務器的效率和管理以及安全都不及數據庫。

關于“nginx如何實現負載均衡分配”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。