负载均衡器已经成为了网站运营领域一个快乐和痛苦的来源。它们的主要目的在于在机器池、或者机器的集群之间分发负载，其延伸范围可以是从数据中心里面最简单到最复杂的设备。负载均衡常常被应用到架构的前端，扮演负责响应来自用户浏览器的数据请求的Web服务器的交通警察。但是，负载均衡器也已经被用于在数据库、中间层应用服务器、跨地域的数据中心和邮件服务器之间来分散负载，这些应用领域的列表还在继续扩展。

负载均衡器基于一个相对简短的算法列表来建立负载分发，使得你能指定协议来达到跨越所有可用的服务器均衡地处理流量。《可扩展互联网架构》—书里，包含了一些在负载均衡器和它们在Web架构中的作用方面很出色的见解。

就我们的目的而言，负载均衡器为容量管理提供了一个非常理想的框架，因为通过它可以在生产环境中方便地进行容量的伸缩。它们也为我们提供了一个各种真实网络流量试验的场所，这样我们就能够跟踪服务器资源上真实的效果。之后你将会看到，为什么这个对于帮助找到你服务器的极限很有用。使用负载均衡是件很爽的事：在部署和研究容量上很方便。

但是也会有些烦恼。因为负载均衡器是架构中很重要的一部分，在发生故障时，也会极其壮观而富戏剧性。不是所有的情况都要求负载均衡。即使是需要负载均衡的时候，也并非所有的均衡算法都恰当。

Jeremy Zawodny在《High Performance MySQL》一书中有这样一个故事，就是Yahoo!的数据库是借由“最小连接数”方案而实现负载均衡的。当对Web服务器进行均衡时，这个方案工作的相当出色：它能确保有最少数量请求的服务 器，有更多的流量指向它。它在Web服务器上工作很好的原因是，Web请求几乎都是短暂（short-lived)的，而且一般不会在大小和延时上有大幅度的变化。尽管如此，这个 范例却不能适用于数据库，因为对于数据库来说，并非所有的查询都是一样的大小、一样的处理时间，而且有些查询结果是非常大的。Zawodny留给我们的教训就是，数据库虽然有相对少的当前连接，却不代表它可以容忍更多的负载。

关于数据库负载均衡的第二个疑虑就是，如何检查在池里的特定服务器的状况，从而确定它们是否都还保持着接收流量的能力。如前所述，数据库是应用程序级别的“野兽”，所以能在我的应用程序上适合的情形并不见得可以在你那能行。对我而言，将复制的从服务器滞后，也许是决定健康的一个因素，然而对于你，也许是SELECT语句的当前频率。

在负载均衡中更多的一些复杂因素包括，罕见的协议、繁杂的均衡算法以及确保负载均衡能使你的应用程序更优化地工作的调优。