http請求分發裝置被稱為負載均衡伺服器。
1. http重定向負載均衡
利用http重定向協議實現負載均衡。
這種負載均衡方案比較簡單。缺點是瀏覽器需要請求兩次伺服器才能完成一次訪問，效能較差；重定向伺服器自身的處理能力成為瓶頸，整個集群伸縮性規模有限；使用http302響應碼重定向，有可能是搜尋引擎判斷為seo作弊，降低搜尋排名。
2. dns網域名稱解析負載均衡
這是利用dns處理網域名稱解析請求的同時進行負載均衡處理的一種方案，
每次網域名稱解析請求都會根據負載均衡演算法計算乙個不同的ip位址返回，這樣a記錄中配置的多個伺服器就構成乙個集群，並可以實現負載均衡。
事實上，大型**總是部分使用dns網域名稱解析，利用網域名稱解析作為第一級負載均衡手段，即網域名稱解析得到的一組伺服器並不是實際提供web服務的物理伺服器，而是同樣提供負載均衡服務的內部伺服器，這組內部負載均衡伺服器在進行負載均衡，將請求分發到真是的web伺服器上。
3. 反向**負載均衡
利用反向**伺服器進行負載均衡。
前面我們提到利用反向**快取資源，以改善**效能。實際上，在部署位置上，反向**伺服器處於web伺服器前面，這個位置也正好是負載均衡伺服器的位置，所以大多數反向**伺服器同時提供負載均衡的功能，管理一組web伺服器，將請求根據負載均衡演算法**到不同web伺服器上。web伺服器處理完成的響應也需要通過反向**伺服器返回給使用者。
由於反向**伺服器**請求在http協議層面，因此也叫應用層負載均衡。其優點是和反向**伺服器繫結在一起，部署簡單。缺點是反向**伺服器是所有請求和響應的中轉站，其效能可能會成為瓶頸。
4. ip 負載均衡
在網路層通過修改請求目標位址進行負載均衡，
這裡的關鍵在於真是物理web伺服器響應資料報如何返回給負載均衡伺服器。一種方案是負載均衡伺服器在修改目的ip位址的同時修改源位址，將資料報源位址設為自身ip，即源位址轉換(snat)，這樣web伺服器的響應會再回到負載均衡伺服器；另一種方案是將負載均衡伺服器同時作為真是物理伺服器集群的閘道器伺服器，這樣所有的響應資料都會到達負載均衡伺服器。
5. 資料鏈路層負載均衡
顧名思義，資料鏈路層負載均衡是指在通訊協議的資料鏈路層修改mac位址進行負載均衡，
這種傳輸方式又稱作三角傳輸模式，負載均衡資料分發過程中不修改ip位址，只修改目的mac位址，通過配置真是物理伺服器集群所有機器虛擬ip和負載均衡伺服器ip位址一致，從而達到不修改資料報的源位址和目的位址就可以進行資料分發的目的，由於實際處理請求的真是物理伺服器ip和資料請求目的ip一致，不需要通過負載均衡伺服器進行位址轉換，可將響應資料報直接返回給使用者瀏覽器，避免負載均衡伺服器網絡卡頻寬成為瓶頸。這種負載均衡方式又稱作直接路由方式(dr)。
使用三角傳輸模式的鏈路層負載均衡是目前大型**使用最廣的一種負載均衡手段。在linux平台上最好的鏈路層負載均衡開源產品是lvs(linux virtual server)。
6. 負載均衡演算法
負載均衡伺服器的實現可以分為兩個部分：
1. 根據負載均衡演算法和web伺服器列表計算得到集群中一台web伺服器的位址。
2. 將請求資料傳送到該位址對應的web伺服器上。
輪詢（round robin，rr）
所有請求被依次分發到每台應用伺服器上，即每台伺服器需要處理的請求數目都相同，適合所有伺服器硬體都相同的場景。
加權輪詢（weighted round robin，wrr）
根據應用伺服器硬體效能的情況，在輪詢的基礎上，按照配置的權重將請求分發到每個伺服器，高效能的伺服器能分配的更多請求。
隨機（random）
請求被隨機分配到各個伺服器，在許多場合下，這種方案都簡單實用，因為隨機數本身就很均衡。即使應用伺服器硬體配置不同，也可以使用加權隨機演算法。
最少連線（least connections）
記錄每個應用伺服器正在出來的連線數(請求數)，將新的請求分發到最少連線數的伺服器上，應該說，這是最符合負載均衡定義的演算法。同樣，最少連線演算法也可以實現加權最少連線。
源位址雜湊（source hashing）
根據請求**ip位址進行hash計算，得到應用伺服器，這樣來自同乙個ip位址的請求總在同乙個伺服器上處理，請求的上下文資訊可以儲存在這台伺服器上，在乙個會話週期內重複使用，從而實現會話黏滯。
應用伺服器集群的伸縮性設計
應用伺服器應該設計成無狀態的，也就是說應用伺服器不儲存請求上下文資訊，如果將部署有相同的應用伺服器組成乙個集群，每次使用者的請求都可以傳送到集群中任意一台伺服器上去處理，任何一台伺服器的處理結果都是相同的。這樣只要能將使用者請求按照某種規則分發到集群中的不同伺服器上，就可以構成乙個伺服器集群了，每個...
架構 應用伺服器集群的伸縮性設計。
應用伺服器應該設計成無狀態，即應用伺服器不儲存請求上下文資訊，如果將部署有相同應用的伺服器組成乙個集群，每次使用者請求都可以傳送到集群中任意一台伺服器上去處理，任何一台伺服器的處理結果都是相同的。這樣只要能將使用者請求按照某種規則分發到集群的不同伺服器上，就可以構成乙個應用伺服器集群，每個使用者的每...
應用伺服器集群Session管理
應用伺服器的高可用架構設計主要基於服務無狀態這一特性，但事實上，業務總是有狀態的，在交易類的電子商務 需要有購物車記錄使用者的購買記錄，使用者每次購買請求都是向購物車中增加商品來社交類 中，需要記錄使用者當前登陸狀態 最新發布的訊息及好友狀態等，使用者每次重新整理頁面都需要更新這些資訊。web應用中...