在實際應用中，在Web伺服器叢集之前總會有一臺負載均衡伺服器，負載均衡裝置的任務就是作為Web伺服器流量的入口，挑選最合適的一臺Web 伺服器，將客戶端的請求轉發給它處理，實現客戶端到真實服務端的透明轉發。最近幾年很火的「雲計算」以及分散式架構，本質上也是將後端伺服器作為計算資 源、儲存資源，由某臺管理伺服器封裝成一個服務對外提供，客戶端不需要關心真正提供服務的是哪臺機器，在它看來，就好像它面對的是一臺擁有近乎無限能力的 伺服器，而本質上，真正提供服務的，是後端的叢集。

高效能和負載均衡兩者一般都是一起提及的，因為他們的關係就和“雞”和“蛋”一樣奇妙，有著千絲萬縷的關係：

首先，要明白高效能負載均衡是如何架構的

1、必須先了解網站架構的伸縮性設計，其分為縱向分離和橫向分離：

縱向分離：將業務處理流程上得不同部分分離部署，實現系統的伸縮性；

橫向分離：將不同的業務模組分離部署，實現系統的伸縮性；

2、常見的負載均衡的實現手段

硬體是實現的負載均衡

優點：負載均衡的效率高，依賴於硬體實現負載均衡，相應的速度快

缺點：商用硬體負載裝置成本通常較高

軟體實現的負載均衡

優點：可以直接使用軟體的方式解決負載均衡，相比於硬體實現，大大降低了成本

缺點：配置較為複雜，相應的速度沒有硬體實現的快

HTTP重定向負載均衡

優點：優點是簡單易行缺點：

瀏覽器需要兩次請求才能完成一次訪問，效能較差；

重定向伺服器自身的處理能力有可能成為瓶頸，整個叢集的伸縮性規模有限；

使用HTTP 302重定向有可能使搜尋引擎判斷為SEO作弊，降低搜尋排名；

DNS域名解析負載均衡

優點：

優點是將負載均衡的工作轉交給了DNS，省掉了網站管理維護負載均衡伺服器的麻煩。

缺點：

目前的DNS是多級解析，每一級DNS都可能快取A記錄，當某臺伺服器下線後，即使修改了DNS的A記錄，要使其生效仍然需要較長時間。這段期間，會導致使用者訪問已經下線的伺服器造成訪問失敗。

DNS負載均衡的控制權在域名服務商那裡，網站無法對其做更多改善和管理；

反向代理負載均衡

優點：優點是和反向代理伺服器功能整合在一起，部署簡單。缺點：缺點是反向代理伺服器是所有請求和響應的中轉站，其效能可能會成為瓶頸。

IP負載均衡

優點：優點在於在核心程序完成資料分發，較反向代理負載均衡（在應用程式中分發資料）有更好的處理效能。缺點：缺點是由於所有請求響應都需要經過負載均衡伺服器，叢集的最大響應資料吞吐量不得不受制於負載均衡伺服器網絡卡頻寬。

資料鏈路層負載均衡

此種方式又稱作三角傳輸模式，負載均衡資料分發過程中不修改IP地址，只修改mac地址，由於實際處理請求的真實物理IP地址和資料請求目的IP地址一致，所以不需要透過負載均衡伺服器進行地址轉換，可將響應資料包直接返回給使用者瀏覽器，避免負載均衡伺服器網絡卡頻寬成為瓶頸。這種負載均衡方式又稱作直接路由方式（DR）。

　　使用三角傳輸模式的鏈路層負載均衡是目前大型網站使用最廣泛的一種負載均衡手段。在Linux平臺上最好的鏈路層負載均衡開源產品是LVS（Linux Virutal Server）。

4、最後介紹一下負載均衡賴以生存的演算法，解決“選誰”的問題

輪詢

所有請求被以此分發到每臺應用伺服器上，即每臺伺服器需要處理的請求數目都相同，適合於所有伺服器硬體都相同的場景。

加權輪詢

根據應用伺服器的配置效能的情況，在輪詢的基礎上，按照配置的權重將請求分發到每個伺服器，高效能的伺服器能分配更多的請求。

隨機

此演算法比較簡單實用，請求被隨機分配到各個應用伺服器，因為好的隨機數本身就很均衡。

最少連線

記錄每個應用伺服器正在處理的連線數（請求數），將新到的請求分發到最少連線的伺服器上，應該說，這是最符合負載均衡定義的演算法。

源地址雜湊

好啦，暫時就說這麼多

參考連結：https://www.cnblogs.com/edisonchou/p/3851333.html