Nginx負載均衡策略

原文連接:https://www.jianshu.com/p/5026ab611d4e

Nginx負載均衡策略

概要

• Nginx工做在OSI的第七層，能夠這對http應用作一些分流策略；
• Nginx反向代理服務的核心主要是轉發Http請求，扮演了瀏覽器後端和後端服務器中轉的角色；
• Nginx官方測試支持5萬併發鏈接，在實際生產環境中能夠到2-3萬併發數鏈接，1萬個非活躍http keep-alive鏈接佔用約2.5M內存。3萬併發鏈接下，10個Nginx進程，消耗內存約150M；
• 負載均衡的目的是爲了解決單個節點壓力過大，致使Web服務響應慢的問題；

內置負載策略

策略

• 輪循(round-robin)默認策略

  • 根據請求次數，將每一個請求均勻分配到每臺服務器,若是後端服務器宕機，自動剔除。

• 權重(Weight)

  • 把請求更多的分配到高配置的後端服務器上，默認每一個服務器的權重都是1。

• ip_hash

  • 同一客戶端的Web請求被分發到同一個後端服務器進行處理，使用該策略能夠有效的避免用戶Session失效的問題。該策略能夠連續產生1045個互異的value，通過20次hash仍然找不到可用的機器時，算法會退化成輪循。

• 最少鏈接(last_conn)

  • Web請求會被轉發到鏈接數最少的服務器上。

  參數說明

  • weight
    • 啓用權重策略，總數按照10進行計算，若是分配爲3，則表示全部鏈接中的30%分配給該服務器,默認值爲1；
  • max_fail/fail_time
    • 某臺服務器容許請求失敗的次數，超過最大數後，在fail_timeout時間內，新的請求不會分配給這臺機器，若是設置爲0，反向代理服務器則會將這臺服務器設置爲永久無效狀態。fail_time默認爲10秒；
  • backup
    • 將某臺服務器設定爲備用機，當列表中的其餘服務器都不可用時，啓用備用機
  • down
    • 將某臺服務器設定爲不可用狀態
  • max_conns
    • 限制分配給某臺服務器的最大鏈接數，超過這個數量，反向代理服務器將不會分配新的鏈接，默認爲0，表示不限制；

  代碼

  http { upstream server_group_name { # ip_hash; # 啓用ip_hash策略 # last_conn; #啓用最少鏈接策略 server ip or domain:port weight=2 max_fails=3 fail_timeout=15 max_conns=1000; # 使用weight設置權重爲20% server ip or domain:port backup; # 設置爲備用機，當其餘服務器所有宕機時，啓用備用服務器 server ip or domain:port down; # 設置服務器爲不可用狀態 } server { listen 80; location / { proxy_pass http://server_group_name; } } } 

擴展策略

策略

• 擴展策略默認不被編譯進nginx內核，若是啓用該策略，須要自行編譯安裝

• fair

  • 根據後臺服務器的響應時間判斷負載狀況，從中選出負載最輕的後端服務。可是在實際請款中，網絡環境每每不那麼簡單，因此慎用。
  • 在編譯安裝後，若是須要啓用該策略，須要在upstream標籤中添加fair;,啓用該策略後，加權輪循將失效。

• url_hash

  • 按照請求url的hash結果來分配請求，試每一個url定向到同一個後端服務器，在1.7.2以後的nginx版本中，該模塊應集成到內核中，不須要單獨安裝。
  • 啓用該策略，須要在upstream標籤中添加hash $request_url;

問題

• 使用Nginx的反向代理，讓同一個用戶的請求必定轉發到同一臺服務器上，這種均衡策略會消耗更多的服務器資源，也增長了代理服務器的負擔；
• 使用其餘策略做爲負載均衡時，會出現用戶Session丟失的狀況，爲避免出現這種狀況，能夠將用戶的Session存放到緩存服務器中，比較經常使用的方案時redis/memchache；
• 反向代理服務器也能夠開啓緩存服務，可是開啓該項服務會增長代理服務器的負擔，影響總體的負載均衡效率；
• 使用Nginx反向代理佈置負載均衡，操做相對金丹，可是會有「單點故障」的問題，若是後臺某臺服務器宕機，會帶來不少的麻煩，後期若是後臺服務器繼續增長，反向代理服務器會成爲負載均衡方案的瓶頸。