负载均衡

现如今，分布式系统非常普遍，而提到分布式系统，就不得不提它其中很重要的一个部分：负载均衡。本文就来介绍一下负载均衡相关的内容。

负载均衡的发展

我们知道当我们自己开发一个小的实验网站的时候，也许就是一台服务器一个数据库就可以了。如下图1所示：

图1 小型实验网站

而当我们开发一个商用的网站，会把他部署到网络上，然后在用户量达到一定量级之后，就需要进行性能的提升。我们聪明的开发者开始把对应的web， application， database都部署到不同的server上，这样相应的server都只要处理特定的内容，从而提升效率和性能，如下图2所示。

图2 小型商用网站

然而很快我们就会发现这样的处理也不能满足我们日益增长的需求，就像我们自己的电脑一样，这个时候就需要进行扩展，扩展的方法总得来说有两种，一种为纵向扩展，就是用更高配置的机器来实现性能的提升，比如以前是双核，我们现在可以改成4核，8核，16核的机器，这样就可以达到性能提升的效果。

然而单个机器的升级毕竟是有极限的，显然不能满足用户数量增长的需求。于是就有了另外一种扩展方式，我们称之为横向扩展，就是通过更多的机器来同时满足类似的需求，这些机器的性能可能都很一般，但是他们组合在一起就能够达到我们所需的结果。如下图3所示。

图3 横向扩展示意图

也就在这个时候负载均衡出现了，简单地说，他就是用来决定如何分发所收到的请求到不同的机器。当它收到相应请求的时候，通过一定的算法，可以决定这个请求发送到哪个服务器，这样一来即使某一个服务器发生问题，也不会影响整体的系统功能的正常运行。我们可以想象，正是有了负载均衡，我们才能够更好地合理使用各个服务器，从而提高响应速度。同时它也可以提高可靠性以及监测分析各个请求的性能从而可以为我们是否需要进行优化提供更好的依据，甚至可以做到动态的优化，比如说发现请求过多，已有的服务器无法做出高效的响应，动态加入更多机器之类的操作。

负载均衡的算法

那么负载均衡是如何来决定相关的请求应该发送到哪一个服务器的呢？这里有两个方面的内容，首先的一点就是会选择一个”健康”的服务器，其次是根据一系列算法来选择一个“最好的”服务器。

健康监测

这个其实很好理解，假如一个服务器已经不能正常进行服务了，比如说断电了，网络断了之类的，那么我们肯定都不应该再选择它。健康监测有很多的方法，总得来说会通过周期性的连接或者请求的发送来确保相应的服务器能够及时的响应，假如负载均衡发现某一个服务器在一段时间内没有反应，那么它就需要把这个服务器从候选列表中清除，直到它恢复正常为止。

算法

负载均衡选择的算法有很多种方法，下面是一些常见的算法：

连接最少：这个方法会选择目前有效连接最少的服务器来发送请求，这个方法对于固定连接分布不均衡的情况比较有效。

响应时间最少：这就是我们俗称的选择响应最快的服务器来进行分发。粗看之下它比较合理，但事实上由于各个请求本身的响应时间有很大差别，如果某一个服务器正好遇到延时很大的请求（请求本身的性能很差），这种方法就会不那么合理。

最大剩余带宽：这种方法会分析目前各个服务已经使用的带宽，然后来看哪一个服务器还有最大的带宽可供使用。

循环：就是从开始一个一个选择对应的服务器，选择到最后一个之后再继续进行下一轮循环。这种方法对各个机器都一样且没有持久连接的情况比较适用。

有权重循环：因为服务器和服务器之间本身可能有差别，比如有些服务器是单核的，有些服务器是双核的，那么直接按照同样权重进行循环就会不太合理，这个时候我们可以给每一个服务器一个权重，让那些高配的服务器有更多的机会被选中，这就是有权重循环。

IP哈希：通过哈希客户端的IP来选择服务器。

冗余负载均衡

从上面我们可以看到负载均衡有很多好处，这时候你不仅会问，假如负载均衡它本身出问题了，岂不是啥都不能做了。是的，所以在现实的设计中，负载均衡也会不止一个，如下图所示，这样一来即使一个负载均衡发生问题，另外一个负载均衡也能够及时取而代之，避免了单点的问题。

 硬件负载均衡

通常我们提到的负载均衡更多指的是软件的负载均衡，事实上还有专门的硬件可以做负载均衡，相比软件来说，硬件负载均衡的性能会更好，但是它的缺点也很明显，就是价格很高。即使是大型的公司一般也只会在比较重要的地方，比如和用户接触的第一个点来使用硬件负载均衡。