負載均衡：是一種服務或基於硬件設備等實現的高可用反向代理技術，負載均衡將特定的業務(web服務、網絡流量等)分擔給指定的一個或多個後端特
定的服務器或設備，從而提高了公司業務的併發處理能力、保證了業務的高可用性、方便了業務後期的水平動態擴展。
（一）HTTP重定向實現負載均衡
過程描述：
當用戶向服務器發起請求時，請求首先被集羣調度者截獲；調度者根據某種分配策略，選擇一臺服務器，並將選中的服務器的IP地址封裝在HTTP響應消息頭部的Location字段中，並將響應消息的狀態碼設爲302，最後將這個響應消息返回給瀏覽器。
當瀏覽器收到響應消息後，解析Location字段，並向該URL發起請求，然後指定的服務器處理該用戶的請求，最後將結果返回給用戶。
在使用HTTP重定向來實現服務器集羣負載均衡的過程中，需要一臺服務器作爲請求調度者。用戶的一項操作需要發起兩次HTTP請求，一次向調度服務器發送請求，獲取後端服務器的IP，第二次向後端服務器發送請求，獲取處理結果。
調度策略： 調度服務器收到用戶的請求後，究竟選擇哪臺後端服務器處理請求，這由調度服務器所使用的調度策略決定。
1、隨機分配策略 ：當調度服務器收到用戶請求後，可以隨機決定使用哪臺後端服務器，然後將該服務器的IP封裝在HTTP響應消息的Location屬性中，返回給瀏覽器即可。
2、輪詢策略(RR)：調度服務器需要維護一個值，用於記錄上次分配的後端服務器的IP。那麼當新的請求到來時，調度者將請求依次分配給下一臺服務器。
由於輪詢策略需要調度者維護一個值用於記錄上次分配的服務器IP，因此需要額外的開銷；此外，由於這個值屬於互斥資源，那麼當多個請求同時到來時，爲了避免線程的安全問題，因此需要鎖定互斥資源，從而降低了性能。而隨機分配策略不需要維護額外的值，也就不存在線程安全問題，因此性能比輪詢要高。
優缺點分析：
採用HTTP重定向來實現服務器集羣的負載均衡實現起來較爲容易，邏輯比較簡單，但缺點也較爲明顯。
在HTTP重定向方法中，調度服務器只在客戶端第一次向網站發起請求的時候起作用。當調度服務器向瀏覽器返回響應信息後，客戶端此後的操作都基於新的URL進行的(也就是後端服務器)，此後瀏覽器就不會與調度服務器產生關係，進而會產生如下幾個問題：
1、由於不同用戶的訪問時間、訪問頁面深度有所不同，從而每個用戶對各自的後端服務器所造成的壓力也不同。而調度服務器在調度時，無法知道當前用戶將會對服務器造成多大的壓力，因此這種方式無法實現真正意義上的負載均衡，只不過是把請求次數平均分配給每臺服務器罷了。
2、若分配給該用戶的後端服務器出現故障，並且如果頁面被瀏覽器緩存，那麼當用戶再次訪問網站時，請求都會發給出現故障的服務器，從而導致訪問失敗。
（二）DNS負載均衡
DNS是什麼：我們知道，數據包採用IP地址在網絡中傳播，而爲了方便用戶記憶，我們使用域名來訪問網站。那麼，我們通過域名訪問網站之前，首先需要將域名解析成IP地址，這個工作是由DNS完成的。也就是域名服務器。
我們提交的請求不會直接發送給想要訪問的網站，而是首先發給域名服務器，它會幫我們把域名解析成IP地址並返回給我們。我們收到IP之後纔會向該IP發起請求。
那麼，DNS服務器有一個天然的優勢，如果一個域名指向了多個IP地址，那麼每次進行域名解析時，DNS只要選一個IP返回給用戶，就能夠實現服務器集羣的負載均衡。
具體做法：首先需要將我們的域名指向多個後端服務器(將一個域名解析到多個IP上)，再設置一下調度策略，那麼我們的準備工作就完成了，接下來的負載均衡就完全由DNS服務器來實現。
當用戶向我們的域名發起請求時，DNS服務器會自動地根據我們事先設定好的調度策略選一個合適的IP返回給用戶，用戶再向該IP發起請求。
優缺點分析：
DNS負載均衡最大的優點就是配置簡單。服務器集羣的調度工作完全由DNS服務器承擔，那麼我們就可以把精力放在後端服務器上，保證他們的穩定性與吞吐量。而且完全不用擔心DNS服務器的性能，即便是使用了輪詢策略，它的吞吐率依然卓越。
此外，DNS負載均衡具有較強了擴展性，你完全可以爲一個域名解析較多的IP，而且不用擔心性能問題。
但是，由於把集羣調度權交給了DNS服務器，從而我們沒辦法隨心所欲地控制調度者，沒辦法定製調度策略。
DNS服務器也沒辦法瞭解每臺服務器的負載情況，因此沒辦法實現真正意義上的負載均衡。它和HTTP重定向一樣，只不過把所有請求平均分配給後端服務器罷了。
此外，當我們發現某一臺後端服務器發生故障時，即使我們立即將該服務器從域名解析中去除，但由於DNS服務器會有緩存，該IP仍然會在DNS中保留一段時間，那麼就會導致一部分用戶無法正常訪問網站。這是一個致命的問題！好在這個問題可以用動態DNS來解決。
（三）反向代理負載均衡
反向代理服務器是一個位於實際服務器之前的服務器，所有向我們網站發來的請求都首先要經過反向代理服務器，服務器根據用戶的請求要麼直接將結果返回給用戶，要麼將請求交給後端服務器處理，再返回給用戶。
之前我們介紹了用反向代理服務器實現靜態頁面和常用的動態頁面的緩存。接下來我們介紹反向代理服務器更常用的功能——實現負載均衡。
我們知道，所有發送給我們網站的請求都首先經過反向代理服務器。那麼，反向代理服務器就可以充當服務器集羣的調度者，它可以根據當前後端服務器的負載情況，將請求轉發給一臺合適的服務器，並將處理結果返回給用戶。
優點：
1、隱藏後端服務器：與HTTP重定向相比，反向代理能夠隱藏後端服務器，所有瀏覽器都不會與後端服務器直接交互，從而能夠確保調度者的控制權，提升集羣的整體性能。
2、故障轉移 ：與DNS負載均衡相比，反向代理能夠更快速地移除故障結點。當監控程序發現某一後端服務器出現故障時，能夠及時通知反向代理服務器，並立即將其刪除。
3、合理分配任務 ：HTTP重定向和DNS負載均衡都無法實現真正意義上的負載均衡，也就是調度服務器無法根據後端服務器的實際負載情況分配任務。但反向代理服務器支持手動設定每臺後端服務器的權重。我們可以根據服務器的配置設置不同的權重，權重的不同會導致被調度者選中的概率的不同。
缺點：
一、調度者壓力過大 ：由於所有的請求都先由反向代理服務器處理，那麼當請求量超過調度服務器的最大負載時，調度服務器的吞吐率降低會直接降低集羣的整體性能。
二、制約擴展 ：當後端服務器也無法滿足巨大的吞吐量時，就需要增加後端服務器的數量，可沒辦法無限量地增加，因爲會受到調度服務器的最大吞吐量的制約。
粘滯會話：
反向代理服務器會引起一個問題。若某臺後端服務器處理了用戶的請求，並保存了該用戶的session或存儲了緩存，那麼當該用戶再次發送請求時，無法保證該請求仍然由保存了其Session或緩存的服務器處理，若由其他服務器處理，先前的Session或緩存就找不到了。
解決辦法1： 可以修改反向代理服務器的任務分配策略，以用戶IP作爲標識較爲合適。相同的用戶IP會交由同一臺後端服務器處理，從而就避免了粘滯會話的問題。
解決辦法2： 可以在Cookie中標註請求的服務器ID，當再次提交請求時，調度者將該請求分配給Cookie中標註的服務器處理即可。
負載均衡組件：
one、apache：它是Apache軟件基金會的一個開放源代碼的跨平臺的網頁服務器，屬於老牌的web服務器了，支持基於Ip或者域名的虛擬主機，支持代理服務器，支持安全Socket層(SSL)等等，目前互聯網主要使用它做靜態資源服務器，也可以做代理服務器轉發請求(如：圖片鏈等)，結合tomcat等servlet容器處理jsp。
two、ngnix：高性能的 HTTP和反向代理服務器。由於Nginx 超越 Apache 的高性能和穩定性，使得國內使用 Nginx 作爲 Web 服務器的網站也越來越多，其中包括新浪博客、新浪播客、網易新聞、騰訊網、搜狐博客等門戶網站頻道等，在3w以上的高併發環境下，ngnix處理能力相當於apache的10倍。
three、HAProxy：HAProxy提供高可用性、負載均衡以及基於TCP和HTTP應用的代理，支持虛擬主機，它是免費、快速並且可靠的一種解決方案。HAProxy特別適用於那些負載特大的web站點， 這些站點通常又需要會話保持或七層處理。HAProxy運行在當前的硬件上，完全可以支持數以萬計的併發連接。並且它的運行模式使得它可以很簡單安全的整合進您當前的架構中， 同時可以保護你的web服務器不被暴露到網絡上.
four、keepalived： 這裏說的keepalived不是apache或者tomcat等某個組件上的屬性字段，它也是一個組件，可以實現web服務器的高可用(HA high availably)。它可以檢測web服務器的工作狀態，如果該服務器出現故障被檢測到，將其剔除服務器羣中，直至正常工作後，keepalive會自動檢測到並加入到服務器羣裏面。實現主備服務器發生故障時ip瞬時無縫交接。它是LVS集羣節點健康檢測的一個用戶空間守護進程，也是LVS的引導故障轉移模塊（director failover）。Keepalived守護進程可以檢查LVS池的狀態。如果LVS服務器池當中的某一個服務器宕機了。keepalived會通過一 個setsockopt呼叫通知內核將這個節點從LVS拓撲圖中移除。
five、memcached：它是一個高性能分佈式內存對象緩存系統。當初是Danga Interactive爲了LiveJournal快速發展開發的系統，用於對業務查詢數據緩存，減輕數據庫的負載。其守護進程(daemon)是用C寫的，但是客戶端支持幾乎所有語言(客戶端基本上有3種版本[memcache client for java;spymemcached;xMecache])，服務端和客戶端通過簡單的協議通信；在memcached裏面緩存的數據必須序列化。
四層負載均衡：僅僅建立一次TCP連接。七層負載均衡：負載均衡器與客戶端及後端的服務器會分別建立一個TCP連接。即兩次TCP連接。
一、所謂四層就是基於IP+端口的負載均衡；七層就是基於URL等應用層信息的負載均衡；同理，還有基於MAC地址的二層負載均衡和基於IP地址的三層負載均衡。 換句換說，二層負載均衡會通過一個虛擬MAC地址接收請求，然後再分配到真實的MAC地址；三層負載均衡會通過一個虛擬IP地址接收請求，然後再分配到真實的IP地址；四層通過虛擬IP+端口接收請求，然後再分配到真實的服務器；七層通過虛擬的URL或主機名接收請求，然後再分配到真實的服務器。
二、所謂的四到七層負載均衡，就是在對後臺的服務器進行負載均衡時，依據四層的信息或七層的信息來決定怎麼樣轉發流量。 比如四層的負載均衡，就是通過發佈三層的IP地址（VIP），然後加四層的端口號，來決定哪些流量需要做負載均衡，對需要處理的流量進行NAT處理，轉發至後臺服務器，並記錄下這個TCP或者UDP的流量是由哪臺服務器處理的，後續這個連接的所有流量都同樣轉發到同一臺服務器處理。七層的負載均衡，就是在四層的基礎上（沒有四層是絕對不可能有七層的），再考慮應用層的特徵，比如同一個Web服務器的負載均衡，除了根據VIP加80端口辨別是否需要處理的流量，還可根據七層的URL、瀏覽器類別、語言來決定是否要進行負載均衡。舉個例子，如果你的Web服務器分成兩組，一組是中文語言的，一組是英文語言的，那麼七層負載均衡就可以當用戶來訪問你的域名時，自動辨別用戶語言，然後選擇對應的語言服務器組進行負載均衡處理。
三、負載均衡器通常稱爲四層交換機或七層交換機。四層交換機主要分析IP層及TCP/UDP層，實現四層流量負載均衡。七層交換機除了支持四層負載均衡以外，還有分析應用層的信息，如HTTP協議URI或Cookie信息。
1、負載均衡分爲L4 switch（四層交換），即在OSI第4層工作，就是TCP層。此Load Balance不理解應用協議（如HTTP/FTP/MySQL等等）。例子：LVS，F5。
2、另一種叫做L7 switch（七層交換），OSI的最高層，應用層。此時，該Load Balance能理解應用協議。例子： haproxy、MySQL、 Proxy。
負載均衡設備也常被稱爲"四到七層交換機"，那麼四層和七層兩者到底區別在哪裏？
####### 一、技術原理上的區別。
所謂四層負載均衡，也就是主要通過報文中的目標地址和端口，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。
以常見的TCP爲例，負載均衡設備在接收到第一個來自客戶端的SYN 請求時，即通過上述方式選擇一個最佳的服務器，並對報文中目標IP地址進行修改(改爲後端服務器IP），直接轉發給該服務器。TCP的連接建立，即三次握手是客戶端和服務器直接建立的，負載均衡設備只是起到一個類似路由器的轉發動作。在某些部署情況下，爲保證服務器回包可以正確返回給負載均衡設備，在轉發報文的同時可能還會對報文原來的源地址進行修改。
所謂七層負載均衡，也稱爲“內容交換”，也就是主要通過報文中的真正有意義的應用層內容，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。
以常見的TCP爲例，負載均衡設備如果要根據真正的應用層內容再選擇服務器，只能先代理最終的服務器和客戶端建立連接(三次握手)後，纔可能接受到客戶端發送的真正應用層內容的報文，然後再根據該報文中的特定字段，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。負載均衡設備在這種情況下，更類似於一個代理服務器。負載均衡和前端的客戶端以及後端的服務器會分別建立TCP連接。所以從這個技術原理上來看，七層負載均衡明顯的對負載均衡設備的要求更高，處理七層的能力也必然會低於四層模式的部署方式。
####### 二、應用場景的需求：
七層應用負載的好處，是使得整個網絡更"智能化"。例如訪問一個網站的用戶流量，可以通過七層的方式，將對圖片類的請求轉發到特定的圖片服務器並可以使用緩存技術；將對文字類的請求可以轉發到特定的文字服務器並可以使用壓縮技術。當然這只是七層應用的一個小案例，從技術原理上，這種方式可以對客戶端的請求和服務器的響應進行任意意義上的修改，極大的提升了應用系統在網絡層的靈活性。很多在後臺，例如Nginx或者Apache上部署的功能可以前移到負載均衡設備上，例如客戶請求中的Header重寫，服務器響應中的關鍵字過濾或者內容插入等功能。
另外一個常常被提到功能就是安全性。網絡中最常見的SYN Flood***，即***控制衆多源客戶端，使用虛假IP地址對同一目標發送SYN***，通常這種***會大量發送SYN報文，耗盡服務器上的相關資源，以達到Denial of Service(DoS)的目的。從技術原理上也可以看出，四層模式下這些SYN***都會被轉發到後端的服務器上；而七層模式下這些SYN***自然在負載均衡設備上就截止，不會影響後臺服務器的正常運營。另外負載均衡設備可以在七層層面設定多種策略，過濾特定報文，例如SQL Injection等應用層面的特定***手段，從應用層面進一步提高系統整體安全。
現在的7層負載均衡，主要還是着重於應用HTTP協議，所以其應用範圍主要是衆多的網站或者內部信息平臺等基於B/S開發的系統。 4層負載均衡則對應其他TCP應用，例如基於C/S開發的ERP等系統。
####### 七層應用需要考慮的問題。
一、是否真的必要，七層應用的確可以提高流量智能化，同時必不可免的帶來設備配置複雜，負載均衡壓力增高以及故障排查上的複雜性等問題。在設計系統時需要考慮四層七層同時應用的混雜情況。
二、是否真的可以提高安全性。例如SYN Flood***，七層模式的確將這些流量從服務器屏蔽，但負載均衡設備本身要有強大的抗DDoS能力，否則即使服務器正常而作爲中樞調度的負載均衡設備故障也會導致整個應用的崩潰。
三、是否有足夠的靈活度。七層應用的優勢是可以讓整個應用的流量智能化，但是負載均衡設備需要提供完善的七層功能，滿足客戶根據不同情況的基於應用的調度。最簡單的一個考覈就是能否取代後臺Nginx或者Apache等服務器上的調度功能。能夠提供一個七層應用開發接口的負載均衡設備，可以讓客戶根據需求任意設定功能，才真正有可能提供強大的靈活性和智能性。
負載均衡（Load Balance）建立在現有網絡結構之上，它提供了一種廉價有效透明的方法擴展網絡設備和服務器的帶寬、增加吞吐量、加強網絡數據處理能力、提高網絡的靈活性和可用性。
負載均衡有兩方面的含義：首先，大量的併發訪問或數據流量分擔到多臺節點設備上分別處理，減少用戶等待響應的時間；其次，單個重負載的運算分擔到多臺節點設備上做並行處理，每個節點設備處理結束後，將結果彙總，返回給用戶，系統處理能力得到大幅度提高。
負載均衡策略的優劣及其實現的難易程度有兩個關鍵因素：一、負載均衡算法，二、對網絡系統狀況的檢測方式和能力。
考慮到服務請求的不同類型、服務器的不同處理能力以及隨機選擇造成的負載分配不均勻等問題，爲了更加合理的把負載分配給內部的多個服務器，就需要應用相應的能夠正確反映各個服務器處理能力及網絡狀態的負載均衡算法：
A、輪循均衡（Round Robin）：每一次來自網絡的請求輪流分配給內部中的服務器，從1至N然後重新開始。此種均衡算法適合於服務器組中的所有服務器都有相同的軟硬件配置並且平均服務請求相對均衡的情況。
B、權重輪循均衡（Weighted Round Robin）：根據服務器的不同處理能力，給每個服務器分配不同的權值，使其能夠接受相應權值數的服務請求。例如：服務器A的權值被設計成1，B的權值是 3，C的權值是6，則服務器A、B、C將分別接受到10%、30％、60％的服務請求。此種均衡算法能確保高性能的服務器得到更多的使用率，避免低性能的服務器負載過重。
C、隨機均衡（Random）：把來自網絡的請求隨機分配給內部中的多個服務器。
D、權重隨機均衡（Weighted Random）：此種均衡算法類似於權重輪循算法，不過在處理請求分擔時是個隨機選擇的過程。
E、響應速度均衡（Response Time）：負載均衡設備對內部各服務器發出一個探測請求（例如Ping），然後根據內部中各服務器對探測請求的最快響應時間來決定哪一臺服務器來響應客戶端的服務請求。此種均衡算法能較好的反映服務器的當前運行狀態，但這最快響應時間僅僅指的是負載均衡設備與服務器間的最快響應時間，而不是客戶端與服務器間的最快響應時間。