在軟件架構設計過程中，解決軟件高并發問題，軟件可用性，及軟件伸縮性等，最好的解決方案就是服務器進行集群，然后負載均衡轉發了。那么負載均衡有哪幾種方案可供選擇，各自的又有什么優缺點了？
一、HTTP重定向負載均衡
HTTP重定向服務器是一臺 普通的應用服務器，其唯一的功能就是根據用戶的HTTP請求計算一臺真實的Web服務器地址,并將該Web服務器地址寫入HTTP重定向響應中(響應狀態碼302 )返回給用戶瀏覽器，瀏覽器再根據響應的地址進行請求。
這種負載均衡方案的優點是比較簡單。缺點是瀏覽器需要兩次請求服務器才能完成一次訪問，性能較差;重定向服務器自身的處理能力有可能成為瓶頸,整個集群的伸縮性規模有限;使用HTTP302響應碼重定向,有可能使搜索引擎判斷為seo作弊,降低搜索排名。因此實踐中使用這種方案進行負載均衡的案例并不多見。
二、DNS域名解析負載均衡
這是利用DNS處理域名解析請求的同時進行負載均衡處理的一種方案,在DNS服務器中配置多個A記錄，如: www.mysite.com IN A 114.100.80.1、www.mysite.com IN A 114.100.80.2、www.mysite.com IN A 114. 100.80.3。每次域名解析請求都會根據負載均衡算法計算一個不同的IP地址返回，這樣A記錄中配置的多個服務器就構成一個集群, 并可以實現負載均衡。
DNS域名解析負載均衡的優點是將負載均衡的工作轉交給DNS，省掉了網站管理維護負載均衡服務器的麻煩，同時許多DNS還支持基于地理位置的域名解析,即會將域名解析成距離用戶地理最近的一個服務器地址，這樣可加快用戶訪問速度，改善性能。
但是DNS域名解析負載均衡也有缺點，就是目前的DNS是多級解析,每一-級DNS都可能緩存A記錄，當下線某臺服務器后,即使修改了DNS的A記錄，要使其生效也需要較長時間，這段時間，DNS依然會將域名解析到已經下線的服務器，導致用戶訪問失敗;而且DNS負載均衡的控制權在域名服務商那里,網站無法對其做更多改善和更強大的管理。
事實上，大型網站總是部分使用DNS域名解析,利用域名解析作為第一級負載均衡手段，即域名解析得到的一組服務器并不是實際提供Web服務的物理服務器，而是同樣提供負載均衡服務的內部服務器，這組內部負載均衡服務器再進行負載均衡，將請求分發到真實的Web服務器上。
三、反向代理負載均衡
通過代向代理服務器，管理一組Web服務器，將請求根據負載均衡算法轉發到不同Web服務器上。Web 服務器處理完成的響應也需要通過反向代理服務器返回給用戶。由于Web服務器不直接對外提供訪問，因此Web服務器不需要使用外部IP地址，而反向代理服務器則需要配置雙網卡和內部外部兩套IP地址。
由于反向代理服務器轉發請求在HTTP協議層面，因此也叫應用層負載均衡。其優點是和反向代理服務器功能集成在一起，部署簡單。缺點是反向代理服務器是所有請求和響應的中轉站，其性能可能會成為瓶頸，不過對于一些并發量不是特別大的網站夠用了。
四、IP負載均衡
IP負載均衡在網絡層通過修改請求目標地址進行負載均衡，用戶請求數據包到達負載均衡服務器后，負載均衡服務器在操作系統內核進程獲取網絡數據包,根據負載均衡算法計算得到一臺真實Web服務器, 然后將數據目的IP地址修改為真實Web服務器, 不需要通過用戶進程處理。真實Web應用服務器處理完成后，響應數據包回到負載均衡服務器，負載均衡服務器再將數據包源地址修改為自身的IP地址發送給用戶瀏覽器。
IP 負載均衡在內核進程完成數據分發，較反向代理負載均衡(在應用程序中分發數據)有更好的處理性能。但是由于所有請求響應都需要經過負載均衡服務器，集群的最大響應數據吞吐量不得不受制于負載均衡服務器網卡帶寬。對于提供下載服務或者視頻服務等需要傳輸大量數據的網站而言，難以滿足需求。能不能讓負載均衡服務器只分發請求，而使響應數據從真實物理服務器直接返回給用戶呢?
五、數據鏈路層負載均衡
顧名思義，數據鏈路層負載均衡是指在通信協議的數據鏈路層修改mac地址進行負載均衡，如圖6.9所示。
這種數據傳輸方式又稱作三角傳輸模式，負載均衡數據分發過程中不修改IP地址，只修改目的mac地址，通過配置真實物理服務器集群所有機器虛擬IP和負載均衡服務器IP地址一致，從而達到不修改數據包的源地址和目的地址就可以進行數據分發的目的，由于實際處理請求的真實物理服務器IP和數據請求目的IP一致,不需要通過負載均衡服務器進行地址轉換，可將響應數據包直接返回給用戶瀏覽器，避免負載均衡服務器網卡帶寬成為瓶頸。這種負載均衡方式又稱作直接路由方式(DR )。
使用三角傳輸模式的鏈路層負載均衡是目前大型網站使用最廣的一種負載均衡手段。如HAproxy,LVS等都是采用這種策略。
