DNS Round Robin(DRR)允许进行廉价的负载平衡(分配是一个更好的术语)。它具有允许无限水平缩放的优点。缺点是，如果其中一台Web服务器出现故障，即使DNS实现了故障转移，某些客户端也会继续使用损坏的IP数分钟(最小TTL 300s)或更长时间。
硬件负载平衡器(HLB)透明地处理此类Web服务器故障，但不能无限扩展其带宽。还需要热备用。
一个好的解决方案似乎是在一组HLB对的前面使用DRR。每个HLB对都不会掉线，因此DRR不会让客户端掉线。另外，当带宽不足时，您可以将新的HLB对添加到组中。
问题:DRR在HLB对之间随机移动客户端，因此(AFAIK) session 粘性无法正常工作。
我可以避免使用 session 粘性，但是可以更好地利用缓存，因此我想保留这种东西。
问题:一个实例可以与其他实例共享其( session ID，Web服务器)映射的HLB实现是否可能/存在？
如果可能，则将由路由请求的HLB将客户端独立路由到同一Web服务器。
提前致谢。
最佳答案
现代的负载平衡器具有很高的吞吐能力(千兆位)。因此，除非您正在运行一个huuuuuuuuuuuge网站(例如google)，否则增加带宽并不是您需要一对新的负载均衡器的原因，尤其是因为大多数大型站点将其大部分带宽都转移给了像Akamai这样的CDN(内容交付网络)。如果您正在通过站点泵送千兆字节的无法CDN的数据，并且还没有全局负载平衡策略，那么与缓存亲缘关系相比，您会遇到更大的问题。 :-)
站点倾向于增加带宽对的分配，而不是限制带宽，以便在单独的数据中心对服务器进行地理分布，以确保分布在世界各地的用户可以与距离他们最近的服务器通信。
对于后一种情况，负载均衡器公司提供了地理位置解决方案，该解决方案(至少直到几年前，那时我一直在关注这些东西)都是基于自定义DNS实现的，该实现着眼于客户端IP并解析为负载均衡器对与客户端“最近”(在网络拓扑或性能方面)的虚拟IP地址。如今，像Akamai这样的CDN也提供全局负载平衡服务(例如http://www.akamai.com/html/technology/products/gtm.html)。 Amazon的EC2托管还为托管在此的站点支持这种功能(请参阅http://aws.amazon.com/elasticloadbalancing/)。
由于用户在单个 session 过程中往往不会在各大洲移动，因此，假设您的用户对位于单独的数据中心，您将自动获得与地理负载平衡的亲和力(又称“粘性”)。
请记住，地理位置定位真的很困难，因为您还必须对数据进行地理位置定位，以确保后端跨数据中心网络不会被淹没。
我怀疑F5和其他供应商也提供了达到相同目的的单数据中心解决方案，如果您确实担心数据中心内部的网络基础结构(路由器等)的单点故障。但是路由器和交换机供应商拥有高可用性解决方案，可能更适合解决该问题。
网络，如果您是我，我将不必担心多对负载均衡器。得到一对，除非您有很多钱和工程时间要花光，否则请与擅长于保持其数据中心网络正常运行的托管服务商合作。
就是说，如果缓存亲和力对您的应用程序来说太大了，您正在考虑为多对负载均衡器投入大量资金，那么可能值得考虑一些应用程序架构更改(例如使用外部缓存集群) 。像memcached(针对Linux)这样的解决方案是针对这种情况而设计的。微软也有一个名为“Velocity”的产品。
无论如何，希望这是有用的信息-自从我深入研究这个领域(我是为大型软件供应商设计应用程序负载均衡产品的团队的成员)以来，已经有一段时间了，所以您可能希望将其增加一倍-通过事实检查您的上述假设，您可以从F5和其他LB供应商那里获得网络支持。
关于session - 负载平衡: DNS round robin in front of hardware load balancers.如何共享粘性？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/1472214/