應用伺服器應該設計成無狀態的，也就是說應用伺服器不儲存請求上下文資訊，如果將部署有相同的應用伺服器組成乙個集群，每次使用者的請求都可以傳送到集群中任意一台伺服器上去處理，任何一台伺服器的處理結果都是相同的。這樣只要能將使用者請求按照某種規則分發到集群中的不同伺服器上，就可以構成乙個伺服器集群了，每個使用者的請求都可能落在不同伺服器上。
負載均衡伺服器：它是個http請求分發裝置，可以感知或者可以配置集群的伺服器數量，可以及時發現集群中新上線或者下線的伺服器，並能向新上線的伺服器分發請求，停止向已下線的伺服器分發請求，這樣負載均衡伺服器就實現了應用伺服器集群的伸縮性了。
下面是實現負載均衡的基本技術
利用http重定向協議實現負載均衡。如下圖
http重定向負載均衡伺服器的唯一功能就是根據使用者的http請求計算一台真實的web伺服器位址，並將該web伺服器位址寫入到http重定向響應中(響應狀態碼302)返回給使用者瀏覽器。
優點：比較簡單
缺點：瀏覽器需要請求兩次伺服器才能完成一次訪問，效能比較差，重定向伺服器自身的處理能力有可能成為瓶頸，使用http302響應碼重定向，有可能使搜尋引擎判斷為seo作弊，降低搜尋排名。
結論：實踐中使用這個方案進行負載均衡的案例很少。
這是利用dns處理網域名稱解析請求的同時進行負載均衡處理的方案，如下圖
在dns伺服器中配置了多個ａ記錄，如：
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依然會將網域名稱解析到已經下線的伺服器，導致使用者訪問失敗，而且dns負載均衡的控制權在網域名稱服務商那裡，**無法對其做更多的改善和針對於自己**的一些修改。
結論：大型**總是部分使用dns網域名稱解析，利用網域名稱解析作為第一級負載均衡手段，即網域名稱解析得到的一組伺服器並不是實際提供web服務的物理伺服器，而是同樣提供負載均衡服務的內部伺服器，這組內部負載均衡伺服器再進行負載均衡，再將請求分發到真實的web伺服器上。
利用反向**進行負載均衡，如下圖：
利用反向**快取資源，可以改善**效能。實際上，在部署位置上，反向**伺服器處於web伺服器前面(這樣才可能快取web響應，加速訪問)，這個位置也正好是負載均衡伺服器所在的位置，所以大多數的反向**伺服器提供了負載均衡的功能，管理一組web伺服器。web伺服器處理完的響應也需要通過反向**伺服器返回給使用者。由於web伺服器不直接對外提供訪問，因此web伺服器不需要使用外部ip位址，而方向**伺服器則需要配置雙網絡卡和內部外部兩套ip位址。
優點：由於反向**伺服器**請求在http協議層面，因此也叫應用層負載均衡，其優點是和反向**伺服器功能整合在一起，部署簡單。
缺點：反向**伺服器是所有請求和響應的中轉站，其效能可能會成為瓶頸
在網路層通過修改請求目的位址進行負載均衡，如下圖
使用者請求資料報到達負載均衡伺服器114.100.80.10後，負載均衡伺服器在作業系統核心程序獲取網路資料報，根據負載均衡演算法計算得到一台真實web伺服器10.0.0.1，然後將資料目的ip修改為10.0.0.1，不需要通過使用者程序處理。真實的web伺服器處理完成後，響應資料報回到負載均衡伺服器，負載均衡伺服器再將資料報源位址修改為自身的ip位址(114.100.80.10)傳送給使用者瀏覽器。
這裡關鍵在於真實物理web伺服器響應資料報如何返回給負載均衡伺服器。一種方案是負載均衡伺服器在修改目的ip位址的同時修改源位址，將資料報源位址設為自身ip，即源位址轉換(snat)，這樣web伺服器的響應會再回到負載均衡伺服器；另一種方案就是將負載均衡伺服器同時作為真實物理伺服器集群的閘道器伺服器，這樣所有響應資料都會到達負載均衡伺服器。
資料鏈路層負載均衡能過實現ip負載均衡中讓負載均衡伺服器只分發請求，而使響應資料從真實物理伺服器直接返回給使用者的需求。資料鏈路層負載均衡是指在通訊協議的資料鏈路層修改mac位址進行負載均衡。如下圖
這種資料傳輸方式又稱作三角傳輸模式。負載均衡資料分發過程中不修改ip位址，只修改mac位址，通過配置真實物理伺服器集群所有機器虛擬ip和負載均衡伺服器ip位址一致，從而達到不修改資料報的源位址和目的位址就可以進行資料分發的目的，由於實際處理請求的真是物理伺服器ip和資料請求目ip一致，不需要通過或負載均衡伺服器進行位址轉換，可將響應資料直接返回給使用者瀏覽器，避免了負載均衡伺服器網絡卡頻寬成為瓶頸。這種負載均衡方式又稱為直接路由方式(dr)
具體的負載均衡演算法通常有下面幾種：
輪詢(round robin, rr)
所有請求被依次分發到每台應用伺服器上，即每台伺服器需要處理的請求數目都相同，適合所有伺服器硬體都相同的情況。
加權輪詢(weighted round robin, wrr)
根據應用伺服器硬體效能的情況，在輪詢的基礎上，按照配置的權重將請求分發到每個伺服器，高效能的伺服器能分配更多的請求
隨機(random)
請求被隨機分配到各個應用伺服器，在許多場合下，這種方案都很簡單實用，因為好的隨機數本身就很均衡。即使應用伺服器硬體配置不同，也可以使用加權隨機演算法
最少連線(least connections)
記錄每個應用伺服器正在處理的連線數(請求數)，將新得到的請求分發到最少連線的伺服器上，應該說，這是最符合負載均衡定義的演算法。同樣，最少連線演算法也可以實現加權最少連線。
源位址雜湊(source hashing)
根據請求**的ip位址進行hash計算，得到應用伺服器，這樣來自同乙個ip位址的請求總在同乙個伺服器上處理，該請求的上下文資訊可以儲存在這台伺服器上，在乙個會話週期內重複使用，從而實現會話粘滯。
應用伺服器集群的伸縮性設計
http請求分發裝置被稱為負載均衡伺服器。1.http重定向負載均衡 利用http重定向協議實現負載均衡。這種負載均衡方案比較簡單。缺點是瀏覽器需要請求兩次伺服器才能完成一次訪問，效能較差 重定向伺服器自身的處理能力成為瓶頸，整個集群伸縮性規模有限 使用http302響應碼重定向，有可能是搜尋引擎判...
架構 應用伺服器集群的伸縮性設計。
應用伺服器應該設計成無狀態，即應用伺服器不儲存請求上下文資訊，如果將部署有相同應用的伺服器組成乙個集群，每次使用者請求都可以傳送到集群中任意一台伺服器上去處理，任何一台伺服器的處理結果都是相同的。這樣只要能將使用者請求按照某種規則分發到集群的不同伺服器上，就可以構成乙個應用伺服器集群，每個使用者的每...
應用伺服器集群Session管理
應用伺服器的高可用架構設計主要基於服務無狀態這一特性，但事實上，業務總是有狀態的，在交易類的電子商務 需要有購物車記錄使用者的購買記錄，使用者每次購買請求都是向購物車中增加商品來社交類 中，需要記錄使用者當前登陸狀態 最新發布的訊息及好友狀態等，使用者每次重新整理頁面都需要更新這些資訊。web應用中...