所有的例子都通過訪問www.ctrip.com為例。這裡只講方案，具體的ngix、lvs、haproxy怎麼工作的等以後細看了再總結。
使用者通過網域名稱解析， 得到ip位址114.100.80.100，訪問這台伺服器，這台機器收到請求之後，因為它是知道伺服器集群裡的ip的， 然後返回乙個重定向到114.100.80.1的請求給使用者的瀏覽器，然後瀏覽器再訪問114.100.80.1。
這個方案致命的缺點就是經過了兩次請求，因為建立http連線的請求的代價是很大的，所以現在採用這種方案的很少。
使用者在訪問www.ctrip.com的時候，在運營商的網域名稱解析伺服器裡會對應多個ip。然後使用者在訪問的時候，只需要直接訪問某乙個ip就可以了。
這種方案看起來很不錯，沒有多次請求，跟沒有集群，訪問當個應用伺服器的效果是一樣的。
但是這個方案如果單獨使用的話，肯定是不行的，因為更新網域名稱解析伺服器裡的ip和網域名稱的對應關係，是有延遲的。比如某台機器掛掉了或者需要發布，要被拉出集群，但是如果用這種方案，使用者還是會訪問到這個ip，這肯定是不行的。
這種方案的典型代表就是ngix，將使用者的請求在內網裡做一次**。而ngix是工作在應用層的，是乙個第七層的協議。需要將包解析，然後**給web伺服器。因此同樣的訪問量的情況下，方向**的吞吐量是遠不如ip負載均衡的。
相對於反向**負載均衡，ip負載均衡直接作用於tcp/ip層，工作在第四層。
使用者請求來了之後，修改請求報文頭里的目的位址，然後**給伺服器集群，不再做一次解包封包的過程。典型的方案是linux裡的lvs模組，中國人寫的哦，相信大家應該都聽說過他的名字——章文嵩。現在貌似已經是**的副總了。
這種方案看起來已經很不錯了，但是其缺點是負載均衡的頻寬問題。每次伺服器返回都會經過ip負載均衡伺服器。如果乙個頁面有2m的大小，這樣的方案其實扛不住多少併發。
那麼最後，終極方案來了：資料鏈路層負載均衡。
這個方案，在第2層，這種資料傳輸方式又稱為三角傳輸，負載均衡資料分發過程中不修改ip位址，只修改目的mac位址，通過配置真實物理伺服器集群所有機器虛擬ip和負載均衡伺服器ip一致，從而達到不修改資料報的源位址和目的位址就可以進行資料分發的目的，由於實際處理請求的真實物理伺服器ip和資料請求目的ip一致，不需要通過負載均衡伺服器進行位址交換，可將響應資料報直接返回給使用者瀏覽器，避免負載均衡伺服器網絡卡頻寬成為瓶頸。這種負載均衡方式又稱之為直接路由方式（dr）.
這個一般由交換機或者路由器來完成。
總結下最佳方案，也是現在使用比較廣泛的方案：dns負載均衡+資料鏈路層負載均衡略略
最簡單，最實用，也是用的最多的演算法。
略就是根據使用者的ip位址，做一次hash然後算到某個ip。這個的好處就是同乙個使用者每次都能算到同乙個ip。但是，雖然能夠實現會話粘滯，我覺得卻並沒有什麼卵用，比如發布的時候，總是算到這台機器，那就悲劇了。所以一般不會用這種演算法。
負載均衡方案總結
負載均衡方案總結 所有的例子都通過訪問www.ctrip.com為例。這裡只講方案，具體的ngix lvs haproxy怎麼工作的等以後細看了再總結。http重定向負載均衡 使用者通過網域名稱解析，得到ip位址114.100.80.100，訪問這台伺服器，這台機器收到請求之後，因為它是知道伺服器集...
負載均衡的方案
負載均衡 在計算機集群 網路連線 cpu 磁碟驅動器或其他資源中分配負載，以達到最佳化資源使用 最大化吞吐率 最小化響應時間 同時避免過載的目的。負載均衡既可以採用硬體實現，也可以採用軟體實現。比較知名的f5負載均衡器，就是基於硬體實現的，效能上優於大部分軟體方式，不過成本也比較昂貴。大部分使用者都...
Discuz NT負載均衡方案
在前面的幾篇文章中，主要談到了在discuz nt中的跨站快取資料，資料庫負載均衡。但如果要實現將產品分布式布置到若干機器，組成集群來共同支撐起整個業務的話，還是有一定問題的 後面會有所介紹 下面先介紹一下如何使用 discuz nt負載均衡方案搭建分布式應用。下面這張圖簡要說明在我們產品中ngin...