DNS輪循（DRR）許可證做便宜的負載均衡（分佈是一個更好的詞）。它有允許無限水平縮放的專業人員。 con是，如果Web服務器中的一個出現故障，一些客戶繼續使用破IP爲分鐘（min TTL 300S）以上，即使DNS工具故障轉移。負載平衡：在DNS的硬件負載均衡器前循環賽。如何分享粘性？
硬件負載平衡器（HLB）透明地處理此類Web服務器故障，但無法無限調整其帶寬。還需要熱備份。
一個好的解決辦法似乎使用DRR在前面的一組HLB對。每個HLB對永遠不會關閉，因此DRR永遠不會讓客戶端停下來。另外，當帶寬不夠時，可以將新的HLB對添加到組中。
問題：DRR隨機地在HLB對之間移動客戶端，因此（AFAIK）會話粘滯性無法工作。
我可以避免使用會話粘性，但它更好地使用緩存，因此是我想保留的內容。
問題：有可能存在一個HLB實現，其中一個實例可以與其他實例共享其（會話id，web服務器）映射嗎？
如果可能，客戶端將被髮送請求的HLB獨立路由到同一個Web服務器。
在此先感謝。
現代負載均衡器有很高高吞吐能力（千兆）。所以除非你運行huuuuuuuuuge站點（例如谷歌），否則增加帶寬並不是爲什麼你需要一對新的負載平衡器，特別是因爲大多數大型站點將他們的大部分帶寬卸載到像Akamai這樣的CDN（內容分發網絡）。如果你抽通過您的網站未CDN-能數據的千兆和還沒有一個全球性的負載均衡策略，你必須比高速緩存的親和力更大的問題。 :-)
取而代之的帶寬限制，網站往往會在不同的數據中心的服務器的地理分佈添加額外的LB配對，確保傳播世界各地的可以跟最親近的人的服務器的用戶。
對於後一種情況下，負載平衡器公司提供的地理定位解決方案，它（至少直到幾年前，當我在下面這個東西這是）是基於它看着客戶端IP地址，並決定自定義DNS實現負載均衡器會將「最接近」（在網絡拓撲或性能方面）的虛擬IP地址與客戶端配對。這些天來，像Akamai的CDN中還提供了全局負載均衡服務（例如：http://www.akamai.com/html/technology/products/gtm.html）。亞馬遜的EC2託管服務也支持這種託管在那裏的網站功能（請參閱http://aws.amazon.com/elasticloadbalancing/）。
由於用戶往往不會跨洲在一個會話的過程中移動，你會自動獲得與地理負載均衡親和力（又名「粘性」），假設你對位於不同的數據中心。
請記住，地理位置是真的困難的，因爲你還必須進行地理定位數據，以確保您的後端跨數據中心的網絡不會被淹沒。
我懷疑F5和其他廠商也提供單數據中心解決方案實現相同的目的，如果你真的關心你的數據中心內的網絡基礎設施（路由器等）的單一故障點。但是路由器和交換機廠商擁有高可用性的解決方案，可能更適合解決這個問題。
淨淨，如果我是你，我就不會擔心多對負載平衡器。找一對，除非你有大量的金錢和工程時間來燒，合作伙伴，主機託管服務提供商誰在保持他們的數據中心網絡運行起來是很好的。也就是說，如果高速緩存親和力對於您的應用程序來說如此重要，以至於您正在考慮爲多對負載均衡器淘汰大額$$$，那麼可能需要考慮一些應用程序體系結構更改（如使用外部緩存集羣）。像memcached（用於Linux）這樣的解決方案是爲這種情況設計的。微軟也有一個名爲「Velocity」的人。
無論如何，希望這是非常有用的信息 - 從我深入參與這個領域（我是團隊的一部分，爲大型軟件供應商設計了一款應用程序負載平衡產品）可能需要仔細檢查我的假設，以及您可以從F5和其他LB供應商處取消網絡的事實。
感謝在正確的角度有放東西。 我同意你的意見。
我做了一些閱讀和發現：
Flickr的：每天http://highscalability.com/flickr-architecture
4十億查詢 - >約50000查詢/秒
的Youtube：http://highscalability.com/youtube-architecture
億次視頻觀看/ day - >大約1200個視頻觀看次數/秒
PlentyOfFish：http://highscalability.com/plentyoffish-architecture
600頁/秒
200 Mbps的使用
CDN使用
Twitter的：http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster
300鳴叫/第二
600 REQ /秒
一個非常頂端LB等this可以擴展：
因此，你是對一個LB很難成爲一個瓶頸。
無論如何，我發現這個（舊）文章http://www.tenereillo.com/GSLBPageOfShame.htm 其中解釋了地理感知DNS可能會產生可用性問題。
可以在那篇文章有人對此有何評論？
感謝，
華倫天奴
好吧，這是一個古老的問題，我只是通過谷歌搜索找到。但對於任何未來的訪問者，這裏有一些額外的說明：
問題：[DNS循環]在HLB對之間隨機地移動客戶端，因此（AFAIK）會話粘度無法工作。
這個前提就是盡我可以告訴不準確的。似乎沒有人知道old browsers might do是什麼，但大概每個瀏覽器窗口只要打開就會保持在同一個IP地址上。較新的操作系統可能是obey the "match longest prefix" rule。因此，不應該有太多'撲動'，從一個負載均衡器IP隨機切換到另一個。
不過，如果你還是擔心有關用戶得到隨機重新分配到新的負載均衡器對，那麼經典的L3/4 & L7負載均衡設置的小的修改可以幫助：
本質上講，這只是一個小的修改到什麼Willy Tarreau (the creator of HAProxy) wrote years ago。
那麼，爲什麼不保持它簡單，並讓DNS服務器根據原始IP地址發出一定的IP地址（即使用基於最終用戶IP的一致散列來始終爲最終用戶提供相同的IP地址（？））？
我知道，這只是提供了簡單和廉價的負載分配機制。
我一直在尋找這一點，但還沒有找到它實現這一點（雖然綁定設有一個享有一定的可能性）的DNS服務器。
沒有DNS服務器，你知道這樣做，但你仍然不協調調用這個保持簡單。 :) – 2014-07-10 06:39:45
將子問題轉移到http://serverfault.com/questions/69864/could-a-geo-dns-create-availability-issues – 2009-09-30 08:02:10