負載均衡的概念

1.1 什麼是負載均衡

Load Balancing，即負載均衡，是一種計算機技術，用來在多個計算機（計算機集羣）、網絡連接、CPU、磁盤驅動器或其他資源中分配負載，以達到最優化資源使用、最大化吞吐率、最小化響應時間，同時避免過載的目的。

簡單來說：負載均衡（Load Balance），即是將負載（工作任務、訪問請求）進行平衡、分攤到多個操作單元（服務器、組件）上進行指向。是解決高性能、單點故障（高可用）、擴展性（水平伸縮）的終極解決方案。

1.2 爲什麼需要負載均衡

從我們生活中來看，經常免不了要去一些人多擁擠的地方，比如火車站、電影院、銀行等等。無論是買票還是排隊入場，這些場所一般都會設置多個服務窗口或者入口的。如果沒有人引導的話，大多數的情況下，最近的窗口或者入口會被擠滿了人，而那些距離較遠的窗口或者入口就寬鬆很多。

針對上面生活中的情況，實際上很浪費資源，因爲如何可以把這些排隊的人很好的分散到各個窗口或者入口將會大大縮短排隊時間。那麼，對於網站或者系統的建設也是一樣的，爲了提升網站的服務能力，很多網站都採用了集羣部署。就像電影院有多個入口一樣，這時候就需要一個協調者，來均衡的分配這些用戶的請求，可以讓用戶的均勻的分派到不同的服務器上。

1.3 負載均衡分類

我們先回顧一下 OSI 七層模型：OSI 是一個開放性的通信系統互聯參考模型，它是一個定義的非常好的協議規範。OSI 模型有7層結構，每層都可以有幾個子層。OSI 的七層從上到下分別是：

7 應用層
6 表示層
5 會話層
4 傳輸層
3 網絡層
2 數據鏈路層
1 物理層

在這七層模型中，高層次都是依賴於低層次的。層次越高，使用起來越方便。其中高層（即 7、6、5、4層）定義來應用程序的功能，下面3層（即3、2、1層）主要面向通過網絡的端到端的數據流。

計算機網絡相關的概念：

TELNET、HTTP、FTP、NFS、SMTP、DNS等屬於第七層應用層的概念。

TCP、UDP、SPX等屬於第四層傳輸層的概念。

IP、IPX等屬於第三層網絡層的概念。

ATM、FDDI等屬於第二層數據鏈路層的概念。

瞭解來網絡協議的七層模型以後，再來看看負載均衡。我們可以很明確的一點是，負載均衡是要在網絡中傳輸做文章的。而要在網絡傳輸過程中，那麼這七層就勢必繞不開。

所以，根據負載均衡技術實現在 OSI 七層模型的不同層次，是可以給負載均衡分類的。

常見的實現方式中，主要可以在應用層、傳輸層、網絡層和數據傳輸層做文章。所以，工作在應用層的負載均衡，我們通常稱之爲七層負載均衡，工作在傳輸層的我們稱之爲四層負載均衡。

大致可以分爲以下機制，其中最常用的是四層和七層負載均衡：

二層負載均衡

一般是用 虛擬mac地址 方式。負載均衡服務器對外提供一個 VIP（虛IP），集羣中不通過的機器採用相同 IP 地址，但是機器的 MAC 地址不一樣。當負載均衡服務器接收到請求之後，通過改寫報文的目標 MAC 地址的方式將請求轉發到目標機器實現負載均衡。

三層負載均衡

一般是用 虛擬IP地址 方式。和二層負載均衡類似，負載均衡服務器對外依然提供一個 VIP（虛IP），但是集羣中不同的機器採用不同的 IP 地址。當負載均衡服務器接收請求之後，根據不同的負載均衡算法，通過 IP 將請求轉發至不同的真實服務器。

四層負載均衡

用 虛擬ip + port 方式。四層負載均衡工作在 OSI 七層模型的傳輸層，由於在傳輸層，只有 TCP/UDP協議，這兩種協議中除了包含源 IP、目標 IP 以外，還包含源端口號以及目的端口號。四層負載均衡服務器在接收到客戶端請求後，以後通過修改數據包的地址信息（IP + 端口號）將流量轉發到應用服務器。

七層負載均衡

用 虛擬的url 或主機名 方式。七層負載均衡工作在 OSI 七層模型的應用層，應用層協議較多，常用http、radius、dns等。七層負載就可以基於這些協議來負載。這些應用層協議中會包含很多有意義的內容。比如同一個 Web 服務器的負載均衡，除來根據 IP + 端口號 進行負載外，還可以根據七層的 URL、瀏覽器類別、語言 來決定是否進行負載均衡。

因爲負載均衡器通常稱爲 四層交換機 或 七層交換機 。這裏針對四層和七層兩者區別再深入說一下：

技術原理區別

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

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

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

以常見的 TCP 爲例，負載均衡設備如果要根據真正的應用層內容再選擇服務服務器，只能先代理最終的服務器和客戶端建立連接（三次握手）後，纔可能接收到客戶端發送的真正應用層內容的報文，然後再根據報文中的特定自帶，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。負載均衡設在這種情況下，更類似於一個代理服務器 。負載均衡和前端的客戶端以及後端的服務器會分別建立 TCP 連接。所以從這個技術原理上來看，七層負載均衡明顯對負載均衡設備的要求更高，處理七層的能力也必然會低於四層模式的部署方式。

應用場景區別

七層因爲可以代理任意修改和處理用戶的請求，所以可以使整個應用更加智能化和安全，代價就是設計和配置會更復雜。所以是否有必要使用七層負載均衡是一個需要權衡的問題。

現在的七層負載均衡，主要還是着重於應用HTTP協議，所以其應用範圍主要是衆多的網站或者內部信息管理平臺等基於 B/S 開發的系統。四層負載均衡則對應其他TCP應用。

1.4 負載均衡工具

市面上有很多開源的負載均衡的工具或軟件，基本都是基於前面提到的方案實現的，大多數是工作在第七層和第四層的。Nginx、LVS、HAProxy 是目前使用最廣泛的三種負載均衡軟件。

LVS：主要用來做四層負載均衡

LVS（Linux Virtual Server），也就是 Linux 虛擬服務器，是一個由章文頌博士發起的自由軟件項目，使用 LVS 技術要達到的目標是：通過LVS提供的負載均衡技術和Linux操作系統實現一個高性能、高可用的服務器集羣架構，它具有良好的可靠性、可擴展性和可操作性。從而以低廉的成本實現最優的服務性能。

Nginx：主要用來做七層負載均衡

Nginx，是一個網頁服務器，它能發現代理HTTP、HTTPS、SMTP、POP3、IMAP的協議鏈接，以及一個負載均衡器和一個HTTP緩存。

Nginx現在的負載均衡既支持四層（ngx_stream_core_module模塊）、又支持七層（ngx_http_upstream_module模塊），但由於LVS在四層負載均衡方面做得知名度實在是太高了，所以Nginx的四層負載均衡用的人不怎麼多，網上也很少會有說用Nginx來做四層負載均衡的。

HAProxy：主要用來做七層負載均衡

HAPorxy，是一個使用 C 語言編寫的自由開源軟件，其提供高可用性、負載均衡，以及基於TCP和HTTP的應用程序代理。

1.5 負載均衡算法

負載均衡服務器在決定將請求轉發到具體哪臺真實服務器的時候，是通過負載均衡算法來實現的。負載均衡算法，是一個負載均衡服務器的核心。

負載均衡算法可以分爲兩類：靜態負載均衡算法 和 動態負載均衡算法 。

靜態負載均衡算法包括：輪詢、比率、優先權

輪詢（Round Robin）：順序循環將請求一次順序循環地連接每個服務器，當其中某個服務器發生第二層到第七層的故障，BIG-IP 就把其從順序循環隊列中拿出，不參加下一次輪詢，直到其恢復正常。
比率（Ratio）：給每個服務器分配一個加權值比例，根據這個比例，把用戶的請求分配到每個服務器。當其中某個服務器發生第二層到第七層的故障，BIG-IP 就把其從服務器隊列中拿出，不參加下一次的用戶請求分配，直到其恢復正常。
優先權（Priority）：給所有服務器分組，給每個組定義優先權，BIG-IP 用戶的請求，分配給優先級最高的服務器組（在同一組內，採用輪詢或比率算法，分配用戶的請求），當最高優先級中所有服務器出現故障，BIG-IP 纔將請求送給次優先級的服務器組。這種方式，實際爲用戶提供一種熱備份的方式。

動態負載均衡算法包括：最少連接數、最快響應速度、觀察方法、預測方法、動態性能分配、動態服務器補充、服務質量、服務類型、規則模式

最少的連接方式（Least Connection）：傳遞新的連接給那些進行最少連接處理的服務器。當其中某個服務器發生第二層到第七層的故障，BIG-IP 就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。
最快模式（Fastest）：傳遞連接給那些響應最快的服務器。當其中某個服務器發生第二層到第七層的故障，BIG-IP 就把其從服務器隊列中拿出，不參加下一次的用戶請求分配，直到其恢復正常。
觀察模式（Observed）：連接數目和響應時間以這兩項的最佳平衡爲依據爲新的請求選擇服務器。當其中某個服務器發生第二層到第七層的故障，BIG-IP 就把其從服務器隊列中拿出，不參加下一次的用戶請求分配，直到其恢復正常。
預測模式（Predictive）：BIG-IP 利用收集到的服務器當前的性能指標，進行預測分析，選擇一臺服務器在下一個時間片內，其性能將達到最佳的服務器響應用戶的請求。（被BIG-IP進行檢測）。
動態性能分配（Dynamic Ratio-APM）：BIG-IP 收集到的應用程序和應用服務器的各項性能參數，動態調整流量分配。
動態服務器補充（Dynamic Server Act.）：當主服務器羣中因故障導致數量減少時，動態地架構備份服務器補充至主服務器羣。
服務質量（QoS）：按不同的優先級對數據流進行分配。
服務類型（ToS）：按不同的服務類型（在Type of Field 中標識）負載均衡對數據流進行分配。
規則模式：針對不同的數據流設置導向規則，用戶可自行。

以上，就是目前實現負載均衡的主流算法，不同的負載均衡服務器會選擇不同的算法。

1.6 軟件負載均衡和硬件負載均衡的比較

使用軟件提供的負載均衡服務和使用硬件提供的負載均衡服務目前都有大規模的應用案例。

軟件負載均衡服務一般都運行在標準的 x86 服務器上，成本往往比硬件負載均衡設備更便宜，同時能更好適應目前流行的雲端服務。

而硬件負載均衡服務則需要特殊設備支持，性能和安全性方面可能會比軟件負載服務更好。

上面瞭解了軟件負載均衡，在這裏稍微延伸下硬件負載均衡相關的一些內容。

什麼是硬件負載均衡？

硬件負載均衡解決方案是直接在服務器和外部網絡間安裝負載均衡設備，這種設備我們通常稱之爲負載均衡器，由於專門的設備完成網絡請求轉發的任務，獨立於操作系統，整體性能高，負載均衡策略多樣化，流量管理智能化。

硬件負載均衡的優缺點是什麼？

優點：直接連接交換機,處理網絡請求能力強，與系統無關，負載性可以強。可以應用於大量設施、適應大訪問量、使用簡單。缺點：成本高，配置冗餘．即使網絡請求分發到服務器集羣，負載均衡設施卻是單點配置；無法有效掌握服務器及應使用狀態。

使用的注意事項以及應用的場景？

注意事項，需要注意的是硬件負載均衡技術只專注網絡判斷，不考慮業務系統與應用使用的情況。有時候系統處理能力已經達到了瓶頸，但是此時網絡並沒有異常，由於硬件負載均衡並沒有察覺到應用服務器的異常，還是讓流量繼續進入到應用服務器。使用場景，一般應用與PV 幾十萬甚至百萬的互聯網應用，一般的軟件負載均衡器例如Nignx 處理併發一般在1-2w，不足以支撐如此大的網絡請求，所以在其之前通常會防止類似F5這樣的硬件負載均衡器幫助控制網絡請求。如果一般的互聯網企業網絡請求數在1w左右的可以考慮使用Nignx（軟件負載均衡器）就足以滿足當前的業務了。

硬件負載均衡器實現哪些功能？

目前市面上有NetScaler, F5, Radware, Array 等產品，基本實現原理大致相同，我們這裏把使用的比較多的 F5作爲例子給大家做簡單解釋，算是窺豹一斑。

多鏈路負載均衡

關鍵業務都需要安排和配置多條ISP（網絡服務供應商）接入鏈路以保證網絡服務的質量。如果某個ISP停止服務或者服務異常了，那麼可以利用另一個ISP替代服務，提高了網絡的可用性。不同的ISP有不同自治域,因此需要考慮兩種情況:INBOUND 和 OUTBOUND。

INBOUND，來自網絡的請求信息。F5 分別綁定兩個ISP 服務商的公網地址,解析來自兩個ISP服務商的DNS解析請求。F5可以根據服務器狀況和響應情況對DNS進行發送,也可以通過多條鏈路分別建立DNS連接。
OUTBOUND，返回給請求者的應答信息。F5可以將流量分配到不同的網絡接口，並做源地址的NAT（網絡地址轉換）,即通過IP地址轉換爲源請求地址。也可以用接口地址自動映射,保證數據包返回時能夠被源頭正確接收。

防火牆負載均衡

針對大量網絡請求的情況單一防火牆的能力就有限了，而且防火牆本身要求數據同進同出，爲了解決多防火牆負載均衡的問題，F5提出了防火牆負載均衡的“防火牆三明治"方案防火牆會對用戶會話的雙向數據流進行監控，從而確定數據的合法性。如果採取多臺防火牆進行負載均衡，有可能會造成同一個用戶會話的雙向數據在多臺防火牆上都進行處理，而單個防火牆上看不到完成用戶會話的信息，就會認爲數據非法因此拋棄數據。所以在每個防火牆的兩端要架設四層交換機，可以在作流量分發的同時，維持用戶會話的完整性，使同一用戶的會話由一個防火牆來處理。而F5 會協調上述方案的配置和實現，把“交換機”，“防火牆”，“交換機”夾在了一起好像三明治一樣。

防火牆“三明治”

服務器負載均衡

對於應用服務器服務器可以在F5上配置並且實現負載均衡，F5可以檢查服務器的健康狀態如果發現故障，將其從負載均衡組中移除。
F5 對於外網而言有一個真實的IP，對於內網的每個服務器都生成一個虛擬IP，進行負載均衡和管理工作。因此,它能夠爲大量的基於TCP/IP的網絡應用提供服務器負載均衡服務。
根據服務類型不同定義不同的服務器羣組。
根據不同服務端口將流量導向對應的服務器。甚至可以對VIP用戶的請求進行特殊的處理，把這類請求導入到高性能的服務器使VIP客戶得到最好的服務響應。
根據用戶訪問內容的不同將流量導向指定服務器。

可用性

自身高可用性，在雙機冗餘模式下工作時實現毫秒級切換。
設備冗餘電源模塊可選。
每臺設備通過心跳線監控其他設備的電頻，發現故障的時候可以完成自動切換。
鏈路冗餘：對鏈路故障進行實時檢測，一旦發現故障進行自動流量切換，過程透明。
服務器冗餘：對服務器進行心跳檢測，一旦發現故障立即從服務器列表中移除，如果恢復工作又重新加入到服務器列表中。

安全性

站點安全防護
拆除空閒連接防止拒絕服務攻擊
能夠執行源路由跟蹤防止IP欺騙
拒絕沒有ACK緩衝確認的SYN防止SYN攻擊
拒絕teartop和land攻擊;保護自己和服務器免受ICMP攻擊

系統管理

提供瀏覽器級別管理軟件，Web圖形用戶界面。

總結：對於高併發，高訪問量的互聯網應用可以考慮加入硬件負載均衡器作爲接入層，協助代理層的軟件負載均衡器進行負載均衡的工作。硬件負載均衡器的特點是獨立於操作系統，處理大訪問量，費用高。從功能上來說支持多鏈路，多服務器，多防火牆的負載均衡，在可用性和安全性上也有良好的表現。

Nginx負載均衡

2.1 Nginx負載均衡介紹

嚴格來說，Nginx 僅僅是作爲 Nginx Proxy 反向代理使用的，因爲這個反向代理功能表現的效果是負載均衡的效果。反向代理可以看下：《Nginx 正向代理與反向代理》

Nginx 負載均衡即支持四層（ ngx_stream_core_module 模塊），也支持七層（ ngx_http_upstream_module 模塊），但由於 LVS 在四層負載均衡用的比較多，知名度也很高。所以 Nginx 的四層負載均衡用的人不怎麼多。

LVS 其實現的功能只是對請求數據包的轉發（也可能會改寫數據包）、傳遞，其中 DR 模式明顯的特徵是從負載均衡下面的節點服務器來看，接收到的請求還是來自訪問負載均衡器的客戶端的真實用戶。
而反向代理不一樣，反向代理接收訪問用戶的請求後，會代理用戶重新發起請求至代理下的節點服務器，最後把數據返回給客戶端用戶，在節點服務器看來，訪問的節點服務器的客戶端用戶就是反向代理服務器了，而非真實的網站訪問用戶。

Nginx 不管是四層還是七層，都是用的同一套 upstream 配置，只是使用這個 upstream 的地方會有差別，所以四層和七層的差別其實對於我們配置來說沒有影響，反正寫起來基本都是通用的。下面會以七層負載均衡爲例進行講解。

不過有一點需要注意，在使用Nginx作爲七層負載均衡器時，如果Nginx上有設置 proxy_cache ，那麼如果被訪問的資源以及被緩存過，Nginx 就不會再將請求轉發給節點，而是直接返回緩存資源。也就是說，在 Nginx 在配置緩存的情況下是有可能不會觸發調度的。

2.2 Nginx負載均衡組件模塊

實現Nginx負載均衡的組件主要有兩個：

ngx_http_upstream_module

負載均衡模塊，可以實現網站的負載均衡功能及節點的健康檢查

ngx_http_proxy_module

proxy 代理模塊，用於把請求轉發給服務器節點或 upstream 服務器池

upstream 模塊

（1）upstream 模塊介紹

upstream 模塊允許 Nginx 定義一組或多組節點服務器組，使用時可以通過 proxy_pass 代理方式把網站的請求發送到事先定義好的對應的 upstream 組的名字上，具體寫法爲：

proxy_pass http://server_pools

其中 server_pools 就是一個 upstream 節點服務器組名字。

（2）upstream配置案例

示例1: 基本的upstream配置案例：

upstream server_pools {
  # upstream是關鍵字必須有，後面的server_pools是upstream集羣組的名字，可自定義名稱，調用時就用這個名字。
  server 192.168.1.251:80 weight=5;
  server 192.168.1.252:80 weight=10;
  server 192.168.1.253:80 weight=15;
  # server關鍵字是固定的，後面可以接域名或IP。如果不指定端口，默認是80端口。weight代表權重，數值越大被分配的請求越多。
}

示例2: 較完整的upstream配置案例：

upstream blog_pools {
  server 192.168.0.223;   #這行標籤和下行是等價的
  server 192.168.0.224:80 weight=1 max_fails=1 fail_timeout=10s;       #這行標籤和上一行是等價的，此行多餘的部分就是默認配置，不寫也可以。
  server 192.168.0.225:80 weight=1 max_fails=2 fail_timeout=20s backup;
  # server最後面可以加很多參數，具體參數作用看下文的表格
}

（3）upstream模塊參數

server ：負載後面的 RS 配置，可以是ip或者域名；
weight ：請求服務器的權重，默認值爲1，越大表示接受的請求比例越大；
max_failsnginx ：嘗試連接後端主機失敗的次數，默認爲1。這個數值需要配合 proxy_next_upstream、fastcgi_next_upstream、memcached_next_upstream 這三個參數來使用的。當 nginx 接收後端服務器返回這三個定義的狀態碼時，會將這個請求轉發給正常工作的後端服務器，例如404、502、503；
fail_timeout ：在 max_fails 定義的失敗次數後，距離下次檢查的時間間隔，默認爲10s
backup ：熱備配置，標誌這臺服務器作爲備份服務器，若主服務器全部宕機，就會向它轉發請求。backup可以被用來做到sorry server的效果，也就是在後端服務器掛了的時候給個“對不起，網站暫時無法訪問”之類的頁面，用來提示用戶。相比於將特定http status code的頁面配置爲類似效果的做法，這種做法的優勢在於不會出現很長時間的超時等待，而是立馬返回錯誤提示，用戶體驗會更好一些；
down ：表示當前server暫時不參與負載均衡，也就是將server標記爲不可用狀態，可配合 ip_hash 使用，實現灰度發佈的效果；
max_conns ：在1.11.5 版本後新增的參數，指連接某後端服務器時最大併發活動連接數。

upstream web_pools {
  server linux.example.com weight=5;
  server 127.0.0.1:8080 max_fail=5 fail_timeout=10s;
  # 當5次連續檢查失敗後，間隔10s後重新檢測。
  server linux.example.com:8080 backup;
  # 指定備份服務器。作用：等上面服務器全部不可訪問時就向它轉發請求。
}

http_proxy_module 模塊

（1）proxy_pass 指令介紹

proxy_pass 指令屬於 ngx_http_proxy_module 模塊，此模塊可以將請求轉發到另一臺服務器。在實際的反向代理工作中，會通過 location 功能匹配指定的 URL，然後把接收到的符合匹配 URL 的請求通過 proxy_pass 拋給定義好的 upstream 節點池。

（2）proxy_pass 的使用案例

location /web/ {
	proxy_pass http://127.0.0.1/abc/;
}

將匹配URL爲web的請求拋給http://127.0.0.1/abc/

（3）http_proxy 模塊參數

2.3 Nginx負載均衡調度算法

rr輪詢（默認的模式）

默認的調度算法，按照客戶端請求逐一分配到不同的後端服務器，宕機的服務器會自動從節點服務器池中剔除。

upstream server_pools {
    server 192.168.1.251;
    server 192.168.1.252;
}
...
location / {
    proxy_pass http://server_pools;
}

注意：對於服務器 性能不同 的集羣，該算法容易引發 資源分配不合理 等問題。

wrr加權輪詢（weight）

在rr輪詢算法的基礎上加上權重，權重和用戶訪問成正比，權重值越大，被轉發的請求也就越多。

upstream web_pools {
  server linux.example.com weight=5;
  server 127.0.0.1:8080 max_fail=5 fail_timeout=10s;
  # 當5次連續檢查失敗後，間隔10s後重新檢測。
  server linux.example.com:8080 backup;
  # 指定備份服務器。作用：等上面服務器全部不可訪問時就向它轉發請求。
}

加權輪詢應用於服務器性能不等的集羣中，使資源分配更加合理化。

ip_hash（會話保持）

每個請求按訪問IP 的 hash 結果分配，每個訪客固定訪問一個後端服務器，可解決 session 不共享的問題。然而由於是非一致性Hash算法，所以一旦節點數量發生變化，所有的分配映射關係就都會發生改變，在節點配置不穩定的情況下會無法達到預期的效果。

upstream server_pools {
    ip_hash;
    server 192.168.1.251;
    server 192.168.1.252;
}

Session 不共享是說，假設用戶已經登陸過，此時發出的請求被分配到了A服務器，但A服務器突然宕機，用戶的請求則會被轉發到B服務器，但由於Session不共享，B無法直接讀取用戶的登陸信息來繼續執行其他操作。

url_hash（web緩存節點）

根據訪問URL的hash結果來分配請求，讓每個URL定向到同一個後端服務器。所以它非常適合在節點服務器爲緩存服務器的情況下使用，能夠大大地提供緩存命中率。然而由於是非一致性Hash算法，所以一旦節點數量發生變化，所有的分配映射關係就都會發生改變，在節點配置不穩定的情況下會無法達到預期的效果。

upstream server_pools {
    hash $request_uri;
    hash_method crc32;
    server 192.168.1.251;
    server 192.168.1.252;
}

Nginx 在1.7.2 版本之前並不支持hash算法，如果需要在舊版中使用這種算法，就需要安裝第三方的hash模塊。配置時只需要在 upstream 配置中增加兩行 hash $request_uri 、 hash_method crc32 。

fair（動態調度算法）

根據後端節點服務器的響應時間來分配請求，響應時間短的優先分配。

upstream server_pools {
    server 192.168.1.251;
    server 192.168.1.252;
    fair;
}

Nginx 本身並不支持fair算法，如果需要使用，就需要安裝第三方的 upstream_fair 模塊。

least_conn（動態調度算法）

根據後端節點服務器的連接數情況來分配請求，連接數少的會被優先分配。

least_conn 可以被用於大量長連接的場景（比如遊戲服務器），它可以幫助節點服務器均分連接，使負載儘可能地保持相同。

least_conn 算法很簡單，它會先遍歷一遍所有的節點，比較它們的連接數，然後選取值最小的哪一個節點。如果有多個節點的連接數都是最小的，那麼就對它們採用加權輪詢算法。可以結合 weight 權重值使用。

upstream balabala {
     least_conn;
     server 192.168.1.251;
     server 192.168.1.252;
}

consistent_hash

consistent_hash 是一個基於一致性 Hash 算法產生的靜態調度算法，它是 ip_hash 和 url_hash 的升級版。

consistent_hash 同樣會把每個請求按照客戶端的IP、請求的URL的Hash結果（參數可選）來分配節點，使得同一個Hash值的請求能夠始終分配到同一個節點上，它的獨特之處在於，一致性Hash算法爲它提供了故障前和一致性保持的效果。也就是說，即使在使用過程中某一個節點宕機了，其他Hash值和對應的節點也還是不會受影響，然後可以保持原來的映射關係；而這一個宕機的節點對應的那些Hash值，會被映射到環上的下一個節點上，達到故障遷移的效果。

配置時和url_hash類似，只需要在upstream配置中加一行consistent_hash $request_uri;即可。同樣，這個參數也是可以替換爲其他內容的。

upstream balabala {
    consistent_hash $request_uri;
    server 192.168.1.251;
    server 192.168.1.252;
}

2.3 Nginx負載均衡配置實例

實現效果

在瀏覽器上輸入地址[http://www.test.com](http://www.test.com),實現負載均衡效果（可平均訪問到兩臺服務器）

準備工作

(1) 準備3臺nginx服務器，如下

主機名IP地址說明web01192.168.1.251Nginx web01服務器web02192.168.1.252Nginx web02服務器lb192.168.1.253Nginx 負載均衡服務器

(2) 三臺服務器均安裝Nginx

Nginx的安裝這裏就不再說了，網上很多參考。

(3) 配置用於測試的Web服務器

分別在web01 和 web02 進行配置

[root@web01 nginx]# cat conf/nginx.conf
worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    server {
        listen       80;
        server_name  localhost;
        location / {
            root   html/www;
            index  index.html index.htm;
        }
	      access_log logs/access_www.log main;
    }
}

創建測試文件數據

[root@web01 ~]# cd /usr/local/nginx/html/
[root@web01 html]# mkdir www
[root@web01 www]# echo "`hostname` www" > index.html

查看創建的文件內容：

[root@web01 www]# cat index.html
web01 www

之後啓動nginx服務。

(4) 配Nginx負載均衡服務器

[root@lb01 nginx]# cat conf/nginx.conf
worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    upstream www_server_pools {         #這裏定義Web服務器池，包含了251，252兩個Web節點
	  server 192.168.1.251:80 weight=1;
	  server 192.168.1.252:80 weight=1;
	}
    server {            #這裏定義代理的負載均衡域名虛擬主機
        listen       80;
        server_name  www.test.com;
        location / {
						proxy_pass http://www_server_pools;     #訪問www.test.com,請求發送給www_server_pools裏面的節點
        }
    }
}

(5) 域名解析由於不是真實環境，域名使用www.test.com用作測試，所以www.test.com 的解析只能在hosts文件設置。

mac系統：

sudo vi  /etc/hosts

windows系統：

C:\Windows\System32\drivers\etc\hosts

在末尾添加:192.168.1.253 www.test.com

測試驗證

打開瀏覽器訪問www.test.com，不斷刷新會發現所有請求被負載均衡服務器（192.168.1.253）均分配到web01（192.168.1.251）和web02（192.168.1.252）上，實現了負載均衡的效果。

負載均衡解析與Nginx實戰