我们有一组共享的静态内容，我们在http://sstatic.net的网站上提供。 不幸的是，这个内容目前不是负载平衡 – 它是从一台服务器提供的。 如果该服务器出现问题，那么所有依赖该服务器的网站都将被closures，因为共享资源是共享的JavaScript库和图像。 我们正在寻找在这台服务器上负载平衡静态内容的方法，以避免单一的服务器依赖。 我意识到，循环赛DNS最好是低端（有些甚至可能会说贫民窟 ）的解决scheme，但我不禁想知道 – 循环赛DNS是一个“足够好”的解决scheme，用于静态内容的基本负载平衡？ 在[dns] [load-balancing]标签中有一些讨论，我已经阅读了关于这个主题的一些很棒的post。 我知道通过多个循环AloggingDNS负载平衡的常见缺点： 通常没有使用DNSlogging进行心跳检测或故障检测，因此如果轮换中的给定服务器出现故障，则必须手动从DNS条目中删除其Alogging 生存时间（TTL）必须设置得相当低，因为DNS的条目在互联网上积极caching 客户端计算机负责看到有多个Alogging并select正确的logging 但是，作为首发者，轮到DNS是足够好的，比没有好，“我们研究和实现更好的替代scheme”forms的静态内容的负载平衡？ 或者在任何情况下，DNS循环都毫无价值？
如果负载均衡器（例如haproxy）后面有5台Web服务器，并且它们为同一个域提供内容，那么是否需要所有服务器的SSL证书，或者您能否在每台服务器上使用相同的证书？ 我知道你可以把所有的SSL请求放在一个特定的服务器上，但这需要分布式的会话信息，并希望它不会这样。