DNS Round Robin（DRR）允许进行廉价的负载均衡（分配是一个更好的术语）。它具有允许无限水平缩放的优点。问题是，如果其中一个Web服务器出现故障，即使DNS实现了故障转移，一些客户端仍会继续使用损坏的IP几分钟（最小TTL 300秒）或更长时间。
硬件负载均衡器（HLB）透明地处理此类Web服务器故障，但无法无限扩展其带宽。还需要一个热备件。
一个好的解决方案似乎是在一组HLB对前面使用DRR。每个HLB对永远不会停机，因此DRR永远不会让客户端失灵。另外，当带宽不足时，您可以向该组添加新的HLB对。
问题：DRR在HLB对之间随机移动客户端，因此（AFAIK）会话粘性不起作用。
我可以避免使用会话粘性，但它可以更好地使用缓存，因此我想保留它。
问题：是否可能/存在HLB实现，其中实例可以与其他实例共享其（sessionid，webserver）映射？
如果可以，那么客户端将被路由该请求的HLB独立路由到同一个Web服务器。
提前致谢。
答案 0 :(得分：6)
现代负载均衡器具有非常高吞吐量功能（千兆位）。因此，除非您运行huuuuuuuuuuge网站（例如谷歌），否则添加带宽并不是您需要一对新的负载平衡器的原因，尤其是因为大多数大型网站将大部分带宽卸载到像Akamai这样的CDN（内容交付网络）。如果您通过您的站点抽取千兆位的无CDN数据并且还没有全局负载平衡策略，那么您遇到的问题比缓存关联性更大。 ： - ）
网站倾向于添加额外的LB对，而不是带宽限制，以便在不同的数据中心对服务器进行地理分布，以确保遍布全球的用户可以与最靠近他们的服务器进行通信。
对于后一种情况，负载均衡器公司提供地理位置解决方案，（至少在几年前，当我关注这些东西时）是基于自定义DNS实现，它查看客户端IP并解决了负载均衡器对与客户端“最接近”（在网络拓扑或性能方面）的虚拟IP地址。目前，像Akamai这样的CDN也提供全球负载平衡服务（例如http://www.akamai.com/html/technology/products/gtm.html）。亚马逊的EC2托管还支持托管在那里的网站的此类功能（请参阅http://aws.amazon.com/elasticloadbalancing/）。
由于用户在单个会话过程中不会跨越各大洲，因此您可以自动获得与地理负载平衡的亲和力（即“粘性”），假设您的对位于不同的数据中心。
请记住，地理位置确实很难，因为您还必须对数据进行地理定位，以确保您的后端跨数据中心网络不会被淹没。
我怀疑F5和其他供应商也提供单数据中心解决方案，如果你真的担心数据中心内网络基础设施（路由器等）的单点故障，那么它们会达到同样的目的。 。但路由器和交换机供应商提供的高可用性解决方案可能更适合解决该问题。
Net-net，如果我是你，我不会担心多对负载均衡器。获得一对，除非你有大量的资金和工程时间进行刻录，否则请与一位擅长保持数据中心网络正常运行的托管商合作。
也就是说，如果缓存亲和力对于您的应用程序来说是如此重要，以至于您正考虑为多对负载均衡器淘汰大型$$$，那么可能值得考虑一些应用程序架构更改（例如使用外部缓存集群）。 memcached（适用于Linux）等解决方案专为此方案而设计。微软也有一个称为“Velocity”。
无论如何，希望这是有用的信息 - 因为我已经深入参与这个领域（我是为大型软件供应商设计应用程序负载平衡产品的团队的一员），所以你可能已经有一段时间了。所以你可能会我想用F5和其他LB供应商从网上下载的事实来仔细检查我的假设。
答案 1 :(得分：3)
好的，这是一个古老的问题，，我刚刚通过Google搜索找到了这个问题。但是对于任何未来的访问者，这里还有一些额外的说明：
问题：[DNS Round Robin]在HLB对之间随机移动客户端，因此（AFAIK）会话粘性不起作用。
这个前提是最好的我可以说不准确。似乎没有人真正知道old browsers might do是什么，但可能只要它打开，每个浏览器窗口都会保留在同一个IP地址上。较新的操作系统可能obey the "match longest prefix" rule。因此，不应该有太多“拍打”，从一个负载均衡器IP随机切换到另一个负载均衡器。
但是，如果您仍然担心关于用户被随机重新分配到新的负载均衡器对，那么对经典L3 / 4＆amp; L7负载均衡设置可以提供帮助：
基本上这只是对Willy Tarreau (the creator of HAProxy) wrote years ago的一个小修改。
答案 2 :(得分：2)
感谢你把事情放在了正确的角度。 我同意你的看法。
我做了一些阅读并发现：
Flickr：http://highscalability.com/flickr-architecture
每天40亿次查询 - ＆gt;大约50000个查询
Youtube：http://highscalability.com/youtube-architecture
每天1亿次视频观看次数 - ＆gt;约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 / s
像this这样的高端LB可以扩展：
因此，你是对的，LB很难成为瓶颈。
无论如何，我发现了这篇（旧）文章http://www.tenereillo.com/GSLBPageOfShame.htm 解释地理感知DNS可能会产生可用性问题。
有人可以评论那篇文章吗？
谢谢，
瓦伦蒂诺
答案 3 :(得分：0)
那么为什么不保持简单并让DNS服务器根据源IP地址给出一定的IP地址（或者使用基于最终用户IP的一致性散列）来给最终用户提供相同的IP地址（es））？
我知道这只提供了一种简单而廉价的负载分配机制。
我一直在寻找这个，但是没有找到实现这个的DNS服务器（尽管Bind有一些观点可能）。