我正在寻找一些可能的负载平衡选项。
到目前为止，我受限于以下选项：
DNS服务器负载平衡器，平衡到一个tomcat服务器集群，用于会话复制的兵马俑。 优点 – 不必购买新的套件。 缺点 – DNS磅可以继续指向一个破碎的服务器。
硬件负载平衡器，直接到tomcat服务器集群。 优点 – 可以有第二个故障转移盒费用。
Apache服务器负载平衡器。 优点 – 阿帕奇的磅调查破碎的服务器。 缺点 – Apache服务器是单点故障，再加上需要购买另一台服务器。
还有其他的select我应该考虑吗？
谢谢。
更新：感谢迄今为止所有的答案+ 1的全部。 还没有接受答案，保持更多的想法来。
我不会去基于DNS的lb – 正是因为你列出的原因。
nginx或varnish可以作为你的其他lb / fail-over选项，位于appservs之前，作为反向代理。 他们确实需要比硬件盒更多的关心，但会为您节省相当多的钱。 一定要将这些平衡器放在一个集群中[主动 – 被动， 心跳也会起作用]。
如果您正在查看负载平衡器设备，那么F5 Big-IP就不会出错
编辑：我刚刚说的与大IP的原因是因为它是一个很好的服务器pipe理员设备，没有太多的networking设备的经验。 它有一个很好的Web界面，configuration和报告几乎是无限的select。 它们是所有“企业”负载平衡选项中最可靠和最便宜的。
以下是2007年关于应用程序交付选项研究的链接： Gartner结果
我build议使用HAProxy 。 速度非常快 您还可以通过使用两个带有CARP（* BSD）或UCARP / LVS（Linux）的负载均衡器来避免单点故障。
多年来，我们一直在使用Coyote Point Equalizers（硬件负载平衡器），并对它们感到非常满意。 他们可能并不具备F5的所有function，但是它们仍然有很多function，而且价格要低得多。 性能和可靠性都非常好。
我倾向于使用硬件LB，因为它们通常可以处理大量stream量，经常是“更简单”，因此能够更好/更容易地被强化，有时也可以pipe理其他安全问题，如硬件中的SYN洪泛攻击。 我使用网捷networking，但有很多的select（F5，思科等） – 花钱虽然:(
思科GSS（全球站点select器）是一个DNS服务器，也进行健康检查。 这显然比标准的DNS服务器更昂贵。 网页上有更多详细信息： http : //www.cisco.com/en/US/products/hw/contnetw/ps4162/index.html
F5 has similar offerings: http://www.f5.com/products/ Cisco ACE product page: http://www.cisco.com/en/US/products/ps8361/index.html 正如Chopper3所提到的那样，基于硬件的负载平衡可能会提供更高的性能，但您将为此付出代价。
您可以查找的function包括：SSL卸载，vlan支持，上下文，集群，对路由协议的支持以及对不同应用程序（例如，html cookie和标头修改）的支持/交互。
你看过ldirectord吗？
它运行在Linux上，可以在同一台机器上运行，并且负载均衡（因此内置了一些冗余） – 或者当然，在它们前面的盒子上，它很容易configuration，轻巧而且function强大。
我发现十字路口是一个优秀的负载平衡器。 它处理我们的生产负载七个月，而networking人员与思科负载平衡器解决硬件问题。
我写了一个基于软件的负载平衡器，不需要单独的机器。
不好的一面是，它不是真正的生产准备 – 但如果你想在你的testingnetworking上testing，我会很高兴。
蓬松的群集在这里
这基本上和微软的NLB（我认为）很相似，尽pipe我没有他们的来源，也不知道他们的工作原理。
当然，我们不会自动监视应用程序层，但您可以编写一些能够改变权重或相应地取出节点的东西。
编辑：你没有说什么操作系统，蓬松的群集目前只有Linux。
keepalived是另一种linux负载均衡器，它支持多种负载平衡algorithm（显然）和VRRP，以在负载平衡器盒故障时创build具有自动故障转移function的冗余实例
如果钱不是一个问题，得到一个硬件负载平衡器。
我工作的公司使用Apache来访问我们的Tomcat服务器，负载均衡器和一些tomcat（tomcat使用内部端口）在同一个盒子上。 我们很快就会转移到一个专门的负载均衡器盒子。 尽pipe我们很快会转向Nginx，但我发现configuration更容易，整体上比Apache更轻。 根据你的networking体系结构，我还build议你为负载均衡器使用一个内部的“浮动IP”，并运行一些类似心跳的东西，以便在必要时将IP切换到另一个盒子。 这将增加故障转移能力，而不用担心DNS传播问题。
我已经用DNSMadeEasybuild立了一个解决scheme。 他们有一个很好的关于DNS故障转移的截屏 。 他们有合理的价格。 在我们的系统中，我们已经实现了一个简单的服务，它可以“ping”我们系统中的不同组件（数据库，JMS队列，S3连接）并返回确定哪个DNSMadeEasy可以使用。 只要出现exception，DNSMadeEasy就会从该DNS查询所答复的服务器列表中删除该服务器。
你看了perlbal？
Hi @toolkit是否曾经在LoadBalancer（LB）任务中实现NGinX / Varnish？ 如果是的话，你的结果是什么？ （如果你不介意与我们其他人分享;-)
只是要总结一下上面（并提到ZMQ）
基本负载平衡
更先进