Nginx負載均衡算法

簡單學習總結

1、負載均衡

一、負載均衡又分爲四層負載均衡和七層負載均衡。

四層負載均衡工做在OSI模型的傳輸層，主要工做是轉發，它在接收到客戶端的流量之後經過修改數據包的地址信息將流量轉發到應用服務器。

七層負載均衡工做在OSI模型的應用層，由於它須要解析應用層流量，因此七層負載均衡在接到客戶端的流量之後，還須要一個完整的TCP/IP協議棧。七層負載均衡會與客戶端創建一條完整的鏈接並將應用層的請求流量解析出來，再按照調度算法選擇一個應用服務器，並與應用服務器創建另一條鏈接將請求發送過去，所以七層負載均衡的主要工做就是代理。

二、軟硬件

1）四層的負載均衡就是基於IP+端口的負載均衡：

對應的負載均衡器稱爲四層交換機（L4 switch），主要分析IP層及TCP/UDP層，實現四層負載均衡。此種負載均衡器不理解應用協議（如HTTP/FTP/MySQL等等）。

實現四層負載均衡的軟件有：

• F5：硬件負載均衡器，功能很好，可是成本很高。
• lvs：重量級的四層負載軟件
• nginx：輕量級的四層負載軟件，帶緩存功能，正則表達式較靈活
• haproxy：模擬四層轉發，較靈活

2）七層的負載均衡就是基於虛擬的URL或主機IP的負載均衡

對應的負載均衡器稱爲七層交換機（L7 switch），除了支持四層負載均衡之外，還有分析應用層的信息，如HTTP協議URI或Cookie信息，實現七層負載均衡。此種負載均衡器能理解應用協議。

實現七層負載均衡的軟件有：

• haproxy：天生負載均衡技能，全面支持七層代理，會話保持，標記，路徑轉移；
• nginx：只在http協議和mail協議上功能比較好，性能與haproxy差很少；
• apache：功能較差
• Mysql proxy：功能尚可。

總的來講，通常是lvs作4層負載；nginx作7層負載；haproxy比較靈活，4層和7層負載均衡都能作。

三、具體實現：

（1）目前負載均衡系統有Nginx、LVS、F5，即：

• Nginx是軟件的7層負載均衡，
  
• LVS是內核的4層負載均衡，
  
• F5是硬件的4層負載均衡。
  

（2）軟件和硬件的區別在於性能，硬件遠遠高於軟件，即：

• Nginx的性能是萬級的，通常的Linux服務器上安裝一個Nginx能達到每秒5萬併發請求；
  
• 而F5的性能能達到百萬級，從200萬每秒到800萬每秒都有，不過價格很貴。
  

（3）4層和7層的區別在於協議和靈活性，即：

• Nginx是7層的，它支持HTTP等協議，
  
• 而LVS和F5是4層協議，它們和協議無關，幾乎全部應用均可以作。
  

2、四層和七層負載均衡的區別？

技術原理上的區別。

所謂四層負載均衡，也就是主要經過報文中的目標地址和端口，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。

以常見的TCP爲例，負載均衡設備在接收到第一個來自客戶端的SYN 請求時，即經過上述方式選擇一個最佳的服務器，並對報文中目標IP地址進行修改(改成後端服務器IP），直接轉發給該服務器。TCP的鏈接創建，即三次握手是客戶端和服務器直接創建的，負載均衡設備只是起到一個相似路由器的轉發動做。在某些部署狀況下，爲保證服務器回包能夠正確返回給負載均衡設備，在轉發報文的同時可能還會對報文原來的源地址進行修改。

所謂七層負載均衡，也稱爲「內容交換」，也就是主要經過報文中的真正有意義的應用層內容，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。

以常見的TCP爲例，負載均衡設備若是要根據真正的應用層內容再選擇服務器，只能先代理最終的服務器和客戶端創建鏈接(三次握手)後，纔可能接受到客戶端發送的真正應用層內容的報文，而後再根據該報文中的特定字段，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。

負載均衡設備在這種狀況下，更相似於一個代理服務器。負載均衡和前端的客戶端以及後端的服務器會分別創建TCP鏈接。因此從這個技術原理上來看，七層負載均衡明顯的對負載均衡設備的要求更高，處理七層的能力也必然會低於四層模式的部署方式。

3、常見的幾種負載均衡算法

一、輪詢法

將請求按順序輪流地分配到後端服務器上，它均衡地對待後端的每一臺服務器，而不關心服務器實際的鏈接數和當前的系統負載。

二、加權輪詢法

不一樣的後端服務器可能機器的配置和當前系統的負載並不相同，所以它們的抗壓能力也不相同。給配置高、負載低的機器配置更高的權重，讓其處理更多的請；而配置低、負載高的機器，給其分配較低的權重，下降其系統負載，加權輪詢能很好地處理這一問題，並將請求順序且按照權重分配到後端。

三、隨機法

經過系統的隨機算法，根據後端服務器的列表大小值來隨機選取其中的一臺服務器進行訪問。由機率統計理論能夠得知，隨着客戶端調用服務端的次數增多，

其實際效果愈來愈接近於平均分配調用量到後端的每一臺服務器，也就是輪詢的結果。

四、加權隨機法

與加權輪詢法同樣，加權隨機法也根據後端機器的配置，系統的負載分配不一樣的權重。不一樣的是，它是按照權重隨機請求後端服務器，而非順序。

五、哈希算法

• 普通哈希：源地址哈希的思想是根據獲取客戶端的IP地址，經過哈希函數計算獲得的一個數值，用該數值對服務器列表的大小進行取模運算，獲得的結果即是客服端要訪問服務器的序號。採用源地址哈希法進行負載均衡，同一IP地址的客戶端，當後端服務器列表不變時，它每次都會映射到同一臺後端服務器進行訪問。
  
• 一致性Hash，相同參數的請求老是發到同一提供者。當某一臺提供者掛時，本來發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引發劇烈變更。一致性hash算法就是把每臺server分紅v個虛擬節點，再把全部虛擬節點（n*v）隨機分配到一致性哈希的圓環上，這樣全部的用戶從本身圓環上的位置順時針往下取到第一個vnode就是本身所屬的節點。當此節點存在故障時，再順時針取下一個做爲替代節點

六、最小鏈接數法

最小鏈接數算法比較靈活和智能，因爲後端服務器的配置不盡相同，對於請求的處理有快有慢，它是根據後端服務器當前的鏈接狀況，動態地選取其中當前

積壓鏈接數最少的一臺服務器來處理當前的請求，儘量地提升後端服務的利用效率，將負責合理地分流到每一臺服務器。

七、IP地址散列

經過管理髮送方IP和目的地IP地址的散列，未來自同一發送方的分組(或發送至同一目的地的分組)統一轉發到相同服務器的算法。當客戶端有一系列業務須要處理而必須和一個服務器反覆通訊時，該算法可以以流(會話)爲單位，保證來自相同客戶端的通訊可以一直在同一服務器中進行處理。

八、URL散列

經過管理客戶端請求URL信息的散列，將發送至相同URL的請求轉發至同一服務器的算法。

4、Nginx的5種負載均衡算法

1. 輪詢

輪詢是默認的方式，每一個請求按時間順序逐一分配到不一樣的後端服務器上。若是後臺服務器上某一臺宕機了，它能夠自動剔除。

缺點：可靠性低和負載分配不均衡。適用於圖片服務器和靜態頁面服務器集羣。

2. 加權輪詢（wight）

指定輪詢的概率，wight和訪問比率成正比，用於後臺服務器性能不均勻的狀況。

upstream linuxidc{       
   server 10.0.0.77 weight=5;       
   server 10.0.0.88 weight=10; 
}複製代碼

3. ip_hash

根據每一個請求的ip的hash結果分配，所以每一個固定ip能訪問到同一個後端服務器，能夠解決session問題。

upstream favresin{      
    ip_hash;      
    server 10.0.0.10:8080;       
    server 10.0.0.11:8080; 
}複製代碼

4. fair（第三方）

按照後端服務器的響應時間來分配請求，響應時間短的優先分配。

upstream favresin{            
      server 10.0.0.10:8080;       
      server 10.0.0.11:8080;       
      fair; 
}複製代碼

5. url_hash（第三方）

按照訪問url的hash結果來分配請求，每一個固定的url訪問同一個後端服務器。若是後端服務器是緩存時效率高。

upstream resinserver{       
      server 10.0.0.10:7777;       
      server 10.0.0.11:8888;       
      hash $request_uri;       
      hash_method crc32; 
}
例：在upstream中加入hash語句，hash_method是使用的hash算法。
複製代碼

在upstream模塊中，能夠經過server命令指定後端服務器的IP地址和端口，同時還能夠設置每臺後端服務器在負載均衡調度中的狀態，

upstream參數解析

• upstream能夠爲每一個設備設置狀態值
  
• down：表示當前的server暫時不參與負載
  
• weight：默認爲1，wight越大，負載的權重越大。
  
• max_fails：容許請求失敗的次數默認爲1.當超過最大次數時，返回proxy_next_upstream模塊定義的錯誤。
  
• fail_timeout：max_fails此失敗後，暫停的時間。
  
• backup：其餘全部非backup機器宕或者忙的時候，請求backup的機器。
  

示例：

tips:
upstream bakend{ #定義負載均衡設備的Ip及設備狀態 
  ip_hash;  
  server 192.0.0.1:8090 weight=5 max_fails=3 fail_timeout=20s;
  server 127.0.0.1:9090 down; 
  server 127.0.0.1:8080 weight=2;    
  server 127.0.0.1:6060;  
  server 127.0.0.1:7070 backup;  
}複製代碼