應用伺服器應該設計成無狀態，即應用伺服器不儲存請求上下文資訊，如果將部署有相同應用的伺服器組成乙個集群，每次使用者請求都可以傳送到集群中任意一台伺服器上去處理，任何一台伺服器的處理結果都是相同的。這樣只要能將使用者請求按照某種規則分發到集群的不同伺服器上，就可以構成乙個應用伺服器集群，每個使用者的每個請求都可以落在不同的伺服器上。如下圖所示。
如果http請求分發裝置可以感知或者可以配置集群的伺服器數量，可以及時發現集群中新上線或下線的伺服器，並能向新上線的伺服器分發請求，停止向已下線的伺服器分發請求，那麼就實現了應用伺服器集群的伸縮性。
這裡，這個http請求分發裝置被稱作負載均衡伺服器。
負載均衡是**必不可少的基礎技術手段，不但可以實現**的伸縮性，同時還改善**的可用性，可謂**的殺手鐗之一。具體的技術實現也多種多樣，從硬體實現到軟體實現，從商業產品到開源軟體，應有盡有，但是實現負載均衡的基礎技術不外以下幾種。
利用http重定向協議實習那負載均衡。如下圖所示。
http重定向伺服器是一台普通的應用伺服器，其唯一的功能就是根據使用者的http請求計算一台真實的web伺服器位址，並將該web伺服器位址寫入http重定向響應中（響應狀態碼302）返回給使用者瀏覽器。在上圖中，瀏覽器請求訪問網域名稱www.mysite.com，dns伺服器解析得到ip位址是114.100.80.10，即http重定向伺服器的ip位址。然後瀏覽器通過ip位址114.100.80.10訪問http重定向負載均衡伺服器後，伺服器根據某種負載均衡演算法計算獲得一台實際物理伺服器的位址（114.100.80.3），構造乙個包含該實際物理伺服器位址的重定向響應返回給瀏覽器，瀏覽器自動重新請求實際物理伺服器的ip位址114.100.80.3，完成訪問。
這種負載均衡方案的優點是比較簡單。缺點是瀏覽器需要兩次請求伺服器才能完成一次訪問，效能較差；重定向伺服器自身的處理能力有可能成為瓶頸，整個集群的伸縮性規模有限；使用http302響應碼重定向，有可能使搜尋引擎判斷為seo作弊，降低搜尋排名。因此實踐中使用這種方案進行負載均衡的案例並不多見。
這是利用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記錄中配置的多個伺服器就構成乙個集群，並可以實現負載均衡。上圖中的瀏覽器請求解析網域名稱www.mysite.com，dns根據a記錄和負載均衡演算法計算得到乙個ip位址114.100.80.3，並返回給瀏覽器；瀏覽器根據該ip位址，訪問真實物理伺服器114.100.80.3。
dns網域名稱解析負載均衡的優點是將負載均衡的工作轉交給dns，聲調了**管理維護負載均衡伺服器的麻煩，同時許多dns還支援基於地理位置的網域名稱解析，即會將網域名稱解析成舉例使用者地理最近的乙個伺服器位址，這樣可加快使用者訪問速度，改善效能。但是dns網域名稱解析負載均衡也有缺點，就是目前的dns是多級解析，每一級dns都可能快取a記錄，當下線某台伺服器後，即使修改了dns的a記錄，要使其生效也需要較長時間，這段時間，dns依然會將網域名稱解析到已經下線的伺服器，導致使用者訪問失敗；而且dns負載均衡的控制權在網域名稱服務商那裡，**無法對其做更多改善和更強大的管理。
事實上，大型**總是部分使用dns網域名稱解析，利用網域名稱解析作為第一級負載均衡手段，即網域名稱解析得到的一組伺服器並不是實際提供web服務的物理伺服器，而是同樣提供負載均衡服務的內部伺服器，這組內部內部負載均衡伺服器再進行負載均衡，將請求分發到真實的web伺服器上。
利用反向**伺服器進行負載均衡，如下圖所示。
前面我們提到利用反向**快取資源，以改善**效能。實際上，在部署位置上，反向**伺服器處於web伺服器前面（這樣才可能快取web響應，加速訪問），這個位置也正好是負載均衡伺服器的位置，所以大多數反向**伺服器同時提供負載均衡的功能，管理一組web伺服器，將請求根據負載均衡演算法**到不同web伺服器上。web伺服器處理完成的響應也需要通過反向**伺服器返回給使用者。由於web伺服器不直接對外提供訪問，因此web伺服器不需要使用外部ip位址，而反向**伺服器則需要配置雙網絡卡和內部外部兩套ip位址。
上圖中，瀏覽器訪問請求的位址是反向**伺服器的位址114.100.80.10，反向**伺服器收到請求後，根據負載均衡演算法計算得到一台真實物理伺服器的位址10.0.0.3，並將請求**給伺服器。10.0.0.3處理完請求後將響應返回給反向**伺服器，反向**伺服器再將該響應返回給使用者。
由於反向**伺服器**請求在http協議層面，因此也叫應用層負載均衡。其優點是和反向**伺服器功能整合在一起，部署簡單。缺點是反向**伺服器是所有請求和響應的中轉站，其效能可能會成為瓶頸。
在網路層通過修改請求目標位址進行負載均衡，如下圖所示。
顧名思義，資料鏈路層負載均衡是指在通訊協議的資料鏈路層修改mac位址進行負載均衡，如下圖所示。
這種資料傳輸方式又稱為三角傳輸模式，負載均衡資料分發過程中不修改ip位址，只修改目的mac位址，通過配置真實物理伺服器集群所有機器虛擬ip和負載均衡伺服器ip位址一致，從而達到不修改資料報的源位址和目的位址就可以進行資料分發的目的，由於實際處理請求的真實物理伺服器ip和資料請求目的ip一致，不需要通過負載均衡伺服器進行位址轉換，可將響應資料報直接返回給使用者瀏覽器，避免負載均衡伺服器網絡卡頻寬成為瓶頸。這種負載均衡方式又稱作直接路由方式（dr）。
在上圖中，使用者請求到達負載均衡伺服器114.100.80.10後，負載均衡伺服器將請求資料的目的mac位址修改為00:0c:29:d2，並不修改數目包目標ip位址，由於web伺服器集群所有伺服器的虛擬ip位址都和負載均衡伺服器的ip位址相同，因此資料可以正常傳輸到達mac位址00:0c:29:d2對應的伺服器，該伺服器處理完成後傳送響應資料到**的閘道器伺服器，閘道器伺服器直接將該資料報傳送到使用者瀏覽器（通過網際網路），響應資料不需要通過負載均衡伺服器。
使用三角傳輸模式的鏈路層負載均衡是目前大型**使用最廣的一種負載均衡手段。在linux平台上最好的鏈路層負載均衡開源產品是lvs（linux virtual server）。
負載均衡伺服器的實現可以分成兩個部分：
前面描述了如何將請求資料傳送到web伺服器，而具體的負載均衡演算法通常有以下幾種。
所有請求被依然分發到每台應用伺服器上，即每台伺服器需要處理的請求數目都相同，適用於所有伺服器硬體都相同的場景。
根據應用伺服器硬體效能的情況，在輪詢的基礎上，按照配置的權重將請求分發到每個伺服器，高效能的伺服器能分配更多請求。
請求被隨機分配到各個應用伺服器，在許多場合下，這種方案都很簡單實用，因為好的隨機數本身就很均衡。即使應用伺服器硬體配置不同，也可以使用加權隨機演算法。
記錄每個應用伺服器正在處理的連線數（請求數），將新到的請求分發到最少連線的伺服器上，應該說，這是符合負載均衡定義的演算法。同樣，最少連線演算法也可以實現加權最少連線。
根據請求**的ip位址進行hash計算，得到應用伺服器，這樣來自同乙個ip位址的請求總在同乙個伺服器上處理，該請求的上下文資訊可以儲存在這台伺服器上，在乙個會話週期內重複使用，從而實現會話黏滯。
應用伺服器集群的伸縮性設計
應用伺服器應該設計成無狀態的，也就是說應用伺服器不儲存請求上下文資訊，如果將部署有相同的應用伺服器組成乙個集群，每次使用者的請求都可以傳送到集群中任意一台伺服器上去處理，任何一台伺服器的處理結果都是相同的。這樣只要能將使用者請求按照某種規則分發到集群中的不同伺服器上，就可以構成乙個伺服器集群了，每個...
應用伺服器集群的伸縮性設計
http請求分發裝置被稱為負載均衡伺服器。1.http重定向負載均衡 利用http重定向協議實現負載均衡。這種負載均衡方案比較簡單。缺點是瀏覽器需要請求兩次伺服器才能完成一次訪問，效能較差 重定向伺服器自身的處理能力成為瓶頸，整個集群伸縮性規模有限 使用http302響應碼重定向，有可能是搜尋引擎判...
應用伺服器集群Session管理
應用伺服器的高可用架構設計主要基於服務無狀態這一特性，但事實上，業務總是有狀態的，在交易類的電子商務 需要有購物車記錄使用者的購買記錄，使用者每次購買請求都是向購物車中增加商品來社交類 中，需要記錄使用者當前登陸狀態 最新發布的訊息及好友狀態等，使用者每次重新整理頁面都需要更新這些資訊。web應用中...