一、什麼是負載均衡
首先我們先介紹一下什麼是負載均衡: 負載平衡（Load balancing）是一種計算機網絡技術，用來在多個計算機（計算機集羣）、網絡連接、CPU、磁盤驅動器或其他資源中分配負載，以達到最佳化資源使用、最大化吞吐率、最小化響應時間、同時避免過載的目的。這是來自維基百科的介紹。負載均衡的目的，就在於平衡負載，給用戶提供優質，可靠，穩定的服務。
上圖是個最簡單的負載均衡實例， 應用服務器並不直接與用戶相連， 用戶連接負載均衡服務器，然後由負載均衡服務器把消息轉發給實際應用服務器。負載均衡器內部會根據應用服務器的負載情況，決定把消息轉發給哪臺服務器處理。同時負載均衡器還可以對用戶屏蔽應用服務器失效，只要把用戶的消息轉發到非失效服務器即可。
提到負載均衡，就不能不介紹另外一個概念： 集羣。集羣就是一組部署有相同應用的服務器。例如web 服務器。用戶的請求無論連接到哪臺服務器上，都能得到相同的處理。這樣我們實現一種服務器，可以將用戶的請求根據特定規則轉發到應用服務器上進行處理。就實現了完整的集羣處理系統。這個服務器如果實現了後臺服務器感知和配置功能，能夠了解後臺服務器的可用情況。就可以被稱作爲負載均衡器。
負載均衡在目前網絡服務規模越來越龐大的情況下，成爲一個大型服務器系統必須要面對的問題。隨着用戶和業務的增多，來自用戶的訪問量和數據流量不斷增大，對服務器的計算能力和儲存要求也在不斷增加，單臺服務器根本無法承擔這麼龐大的數據處理請求。這個時候，我們必須利用集羣技術，採用一組服務器對來自用戶的請求進行處理，服務器的數量要能夠不斷的擴充。在集羣的前端，我們採用負載均衡技術，平均分散用戶的請求到不同的處理服務器，並且能夠在集羣中某個服務失效時，即時感知，屏蔽，將消息轉發到其他可用服務器上。
負載均衡分爲硬件和軟件：
(1).硬件LB（比較出名的）
F5 公司的 BIG-IP系列、Citrix 公司的 NetScaler系列、A10 公司的 AX系列
(2).軟件LB
四層：LVS(Linux VirtualServer)注：國人開發的、七層：Nginx,HAProxy
二、集羣的類型
1.scale on:向上擴展
將服務器的內存容量調大和cpu數量增加些（簡單說升級服務器硬件）
缺點:在一定的範圍之內它的性能是上升的趨勢,但是超出範圍之後就是下降的趨勢。因爲隨着它的cpu的個數增加我們需要給我們的cpu仲裁，而且隨着cpu個數的增加資源競爭性越大。
2.scale out:向外擴展
一臺服務器應付不過來,我們就再增加一臺服務器。
優點:增減服務器很方便，而且沒有向上擴展隨着增加性能下降。
向外擴張的工作模式：當客戶端向服務器端發送請求，服務器端只拿出來一臺服務器來相應我們的客戶端的請求。
(1).LB:Load Balancing:負載均衡集羣
負載均衡集羣中有一個分發器或者叫調度器，我們將其稱之爲Director，它處在多臺服務器的上面，分發器根據內部鎖定義的規則或調度方式從下面的服務器羣中選擇一個以此來響應客戶端發送的請求。
(2).HA:High Availability 高可用集羣
高可用集羣是服務的可用性比較高，當我們某臺服務器死機後不會造成我們的服務不可用。其工作模式則是將一個具有故障的服務轉交給一個正常工作的服務器，從而達到服務不會中斷。一般來說我們集羣中工作在前端（分發器）的服務器都會對我們的後端服務器做一個健康檢查，如果發現我們服務器當機就不會對其在做轉發。
衡量標準：可用性=在線時間/(在線時間+故障處理時間) 99%、99.9%、99.99%、99.999%
(3).HP:Hight Performance 高性能
高性能的集羣是當某一個任務量非常大的時候，我們做一個集羣共同來完成這一個任務。這種處理方式我們稱爲並行處理集羣，並行處理集羣是將大任務劃分爲小任務，分別進行處理的機制。一般這樣的集羣用來科學研究與大數據運算等方面的工作。現在比較火的Hadoop就是使用的並行處理集羣。
說明：三種集羣之間的區別
負載均衡着重在於提供服務併發處理能力的集羣，高可用以提升服務在線的能力的集羣。高性能着重用於處理一個海量任務。
三、主要負載均衡方案介紹
1:HTTP 重定向負載均衡
這種負載均衡方式僅適合WEB 服務器。用戶發出請求時，負載均衡服務器會根據HTTP請求，重新計算出實際的WEB服務器地址，通過302重定向相應發送給用戶瀏覽器。用戶瀏覽器再根據302響應信息，對實際的WEB服務器發出請求。HTTP重定向方案有點是比較簡單，缺點是性能比較差，需要2次請求才能返回實際結果,還有就是僅適合HTTP服務器使用。
2: DNS 域名解析負載均衡
在DNS中存儲了一個域名的多個主機地址，每次域名解析請求，都可以根據負載均衡算法返回一個不同的IP地址。這樣多個WEB服務器就構成了一個集羣，並由DNS服務器提供了負載均衡服務。DNS域名解析負載均衡的優點是由DNS來完成負載均衡工作，服務本身不用維護負載均衡服務器的工作。缺點也是，由於負載均衡服務器不是自己維護，沒法做精細控制，而且DNS在客戶端往往帶有緩存，服務器的變更很難及時反映到客戶端上。
3：反向代理負載均衡
反向代理服務器位於實際的服務器之前，他能夠緩存服務器響應，加速訪問，同時也啓到了負載均衡服務器的效果。反向代理服務器解析客戶端請求，根據負載均衡算法轉發到不同的後臺服務器上。用戶和後臺服務器之間不再有直接的鏈接。請求，響應都由反向代理服務器進行轉發。優點是和負載均衡服務集成在一起，部署簡單。缺點是所有的請求迴應都需要經過反向代理服務器。其本身可能會成爲性能的瓶頸。著名的 Nginx服務器就可以部署爲反向代理服務器，實現WEB 應用的負載均衡。上面的三種都是工作在OSI網絡模型中的應用層，我們可以統稱爲應用層負載均衡(七層負載均衡)。下面介紹的幾種工作在OSI網絡模型中的4層以及4層以下(四層負載均衡)，解決方案也具有更大的通用性。
4：IP負載均衡
用戶請求包到達負載均衡服務器114.100.20.200後，負載均衡服務器在操作系統內核層獲取網絡數據包，根據負載均衡算法獲取真實後臺服務器地址192.168.1.1, 然後將數據包的目標地址改爲192.168.1.1, 轉發給內部服務器。整個過程都在內核層進行處理。收到192.168.1.1的響應包之後，會更改響應包的SRC IP, 轉發給客戶端用戶。採用IP層負載均衡算法，全部處理過程都在內核層(Ring 0)進行。和七層負載均衡相比，具有更好的性能。但是由於所有的響應包都要經過負載均衡服務器，負載均衡服務器的網卡帶寬，很容易成爲系統的瓶頸，如果能夠讓響應包不經過負載均衡服務器，就可以極大的提升整個負載均衡服務器的服務能力。我們下面介紹的數據鏈路層負載均衡，就具有這個能力。
5：數據鏈路層負載均衡
數據鏈路層負載均衡，顧名思義，就是工作在TCP/IP協議最底層的數據鏈路層，進行負載均衡。我們常用的以太網中，在這一層主要採用數據幀進行通信，每個網卡都具有唯一的MAC地址，數據幀用MAC地址來標識數據的來源與目的地。數據鏈路層負載均衡通過修改數據包的MAC地址，實現負載均衡。
這種數據傳輸方式又稱爲三角傳輸，負載均衡數據分發過程中不修改IP地址，只修改目的MAC地址，通過配置真實物理服務器集羣所有機器虛擬IP和負載均衡服務器IP一致，從而達到不修改數據包的源地址和目的地址就可以進行數據分發的目的，由於實際處理請求的真實物理服務器IP和數據請求目的IP一致，不需要通過負載均衡服務器進行地址交換，可將響應數據包直接返回給用戶，避免負載均衡服務器網卡帶寬成爲瓶頸。這種負載均衡方式又稱之爲直接路由方式（DR）.
如上圖所示，用戶請求到達負載均衡服務器114.100.20.200後，負載均衡服務器將數據包的目的MAC地址更改爲00:1e:ec:bc:5e:03，並不修改數據包目的IP，由於服務器集羣所有服務器的虛擬IP地址和負載均衡服務器IP地址一致，因此數據可以正常傳輸到達MAC地址爲00:1e:ec:bc:5e:03的機器上，該服務器處理完之後，將響應數據包發送到網關服務器，網關服務器直接將數據包發送給用戶，響應數據不需要通過負載均衡服務器，這樣就避免了負載均衡服務器成爲傳輸瓶頸的可能。
數據鏈路層負載均衡是目前使用最廣泛的一種負載均衡方式。著名的負載均衡開源產品LVS(Linux Virtual Server)，同時支持上面的IP負載均衡和數據鏈路層負載均衡。是學習負載均衡技術必須瞭解的產品。基於數據鏈路層的負載均衡雖然有非常好的性能，但是對網絡拓撲也有比較大的限制，負載均衡服務器和後臺服務器必須處於同一網絡環境中纔可以。
四、負載均衡算法介紹
前面介紹的內容，解決了從用戶到實際後臺服務器之間的數據包發送和響應的問題。下面我們介紹選擇實際後臺運行服務器的具體負載均衡算法。考慮到服務請求的不同類型服務器的不同處理能力以及隨機選擇造成的負載分配不均勻等問題,爲了更加合理的把負載分配給內部的多個服務器,就需要應用相應的能夠正確反映各個服務器處理能力及網絡狀態的負載均衡算法。我們以LVS爲參考，介紹比較經典的8種負載均衡算法。
1.輪叫調度(Round Robin)
調度器通過“輪叫"調度算法將外部請求按順序輪流分配到集羣中的真實服務器上,它均等地對待每一臺服務器,而不管服務器上實際的連接數和系統負載
2.加權輪叫(Weighted Round Robin)
調度器通過“加權輪叫"調度算法根據真實服務器的不同處理能力來調度訪問請求這樣可以保證處理能力強的服務器能處理更多的訪問流量調度器可以自動問詢真實服務器的負載情況,並動態地調整其權值
3.最少鏈接(Least Connections)
調度器通過“最少連接"調度算法動態地將網絡請求調度到已建立的鏈接數最少的服務器上如果集羣系統的真實服務器具有相近的系統性能,採用“最小連接"調度算法可以較好地均衡負載
4.加權最少鏈接(Weighted Least Connections)
在集羣系統中的服務器性能差異較大的情況下,調度器採用“加權最少鏈接"調度算法優化負載均衡性能,具有較高權值的服務器將承受較大比例的活動連接負載調度器可以自動問詢真實服務器的負載情況,並動態地調整其權值
5.基於局部性的最少鏈接(Locality-Based Least Connections)
“基於局部性的最少鏈接"調度算法是針對目標IP地址的負載均衡,目前主要用於Cache集羣系統該算法根據請求的目標IP地址找出該目標IP地址最近使用的服務器,若該服務器是可用的且沒有超載,將請求發送到該服務器;若服務器不存在,或者該服務器超載且有服務器處於一半的工作負載,則用“最少鏈接"的原則選出一個可用的服務器,將請求發送到該服務器
6.帶複製的基於局部性最少鏈接(Locality-Based Least Connections with Replication)
“帶複製的基於局部性最少鏈接"調度算法也是針對目標IP地址的負載均衡,目前主要用於Cache集羣系統它與LBLC算法的不同之處是它要維護從一個目標IP地址到一組服務器的映射,而LBLC算法維護從一個目標IP地址到一臺服務器的映射該算法根據請求的目標IP地址找出該目標IP地址對應的服務器組,按“最小連接"原則從服務器組中選出一臺服務器,若服務器沒有超載,將請求發送到該服務器;若服務器超載,則按“最小連接"原則從這個集羣中選出一臺服務器,將該服務器加入到服務器組中,將請求發送到該服務器同時,當該服務器組有一段時間沒有被修改,將最忙的服務器從服務器組中刪除,以降低複製的程度
7.目標地址散列(Destination Hashing)
“目標地址散列"調度算法根據請求的目標IP地址,作爲散列鍵(Hash Key)從靜態分配的散列表找出對應的服務器,若該服務器是可用的且未超載,將請求發送到該服務器,否則返回空
8.源地址散列(Source Hashing)
“源地址散列"調度算法根據請求的源IP地址,作爲散列鍵(Hash Key)從靜態分配的散列表找出對應的服務器,若該服務器是可用的且未超載,將請求發送到該服務器,否則返回空
文章內容及圖片爲編者筆記，大部分摘自網絡，如有侵權，請第一時間聯繫我！
原文鏈接：http://blog.51cto.com/linuxnote/1654565