负载均衡器是一个非常重要的组件在一个分布式系统中。它能够帮助解决2个问题。一个是可以把请求平均的分发到每一个服务器上，或者别的后台上。另一个是当一个SERVER挂了的时候，他会知道这个SERVER不可用，而把这个SERVER的流量转到别的好的SERVER上。
前者的好处，是我们分摊了单个SERVER的流量，可以使得他运行得更轻松（快速）。后者的好处我们可以从单点失效的困境中解脱出来。
综上我们可以提高我们系统的可用性（根据后者）和响应速度（前者）
负载均衡器可以架构在3个地方。
一个是USER 的client 和 web server间。
例子就是BROWSER 发一个 HTTP请求 到你的APACHE SERVER上。中间可能会有一层NIGNX帮你做了负载均衡，如果你有多个APACHE SERVER的话。
第二个是WEBSERVER 到 APP SERVER间的通讯。
APACHE 可能把这个请求解析完成后，找到对应提供服务的APP SERVER去转发请求。这个时候如果APP SERVER 有多个，那么可以做负载均衡。这里我熟悉的是 SPRING CLOUD 里的RIBBON
第三个就是APP SERVER 要和DB 通讯的时候，也可以加负载均衡。
负载均衡的优点
如果有人详细的问你你能说出负载均衡到底有哪些优点。
那么除了上面提到的2个，负载均衡还可以有更多。
首先回顾下前面说的2个。
1.用户会得到更快的响应，因为当一个SERVER在努力处理别人请求时，你的REQUEST会被分配到空闲的SERVER上。就加速了响应速度。
2.不怕一个服务器挂了，同时服务器也会因此获得高吞吐。
3.让系统的ADMIN能够很轻松的处理所有到来的请求，并且分发出去。（如果没有LB，我们要自己实现很麻烦）
4.如果一些智能的LB可以分析请求以及预测请求，然后可以解决一些传输瓶颈在他发生前。
5.整体上看的好处是系统ADMIN 会 遇到更少的失败和更少的负担过重的SERVER。
负载均衡的算法
负载均衡如何知道哪些SERVER挂了很重要，因为在前面的逻辑里。负载均衡是不会把请求转发到一个挂的SERVER上的。
这是通过心跳来实现，每隔一段时间服务器会往LB上发我还活着。如果超过一段时间没收到一个SERVER的我还活着。那么LB就会把它从好SERVER的pool里移除。
在所有的好SERVER中，LB会根据用户给定的算法来分发请求。
算法1. 最少链接，会去找每个SERVER的连接数，找到最少的那个，把请求转给它。这个算法最大的用处是在那些需要维护很多个持久连接的应用中。
算法2，最少响应时间。 把请求转给那些平均响应时间最低的。
算法3， 最少带宽。 把请求给那些带宽占用最少的。单位是MBPS。megabits per second.
算法4， ROUND ROBIN。 就是一个环，一个一个来。比如说1->2->1 这个环，就是先发1，再发2，再发1，再发2.。。。
算法5，带权重的ROUND ROBIN。因为考虑到不同SERVER的性能不一样，比如SERVER的硬件性能是SERVER 1 的二倍。我们可以这样构建环。 1->2->2->1. 第一个请求去1，第二第三个都去2.第4个去1，第5,6个都去2.
算法6，IP HASH。 这个算法就是根据请求的IP 地址做HASH，然后分配到对应的server. 有点RANDOM选的感觉。
备份负载均衡器
因为引入了负载均衡器，那么这个组件可能会带来单点失效的问题。
为了解决这个问题，我们可以引入2个负载均衡器。他们彼此监听对方的心跳，如果一个发现另一个死了。他就立刻上位替代对方，担起重任。
实现负载均衡器的三个方法
1.智能客户端。程序员在开发这个程序的时候，在里面就内嵌好了负载均衡器，程序本身会智能的做请求分发。这个客户端为维护一组要连的HOST的池子，检查健康，然后转发。有些甚至还可以做到去修复那些不健康的HOST。但是当系统变得很大，这个方式不容易扩展，我们需要把LB 提出来单独建立一层。
2.硬件实现的
LB可以由硬件直接实现，通过硬件实现的LB，性能超级出色。唯一的缺点就是贵。出于经济考虑，只有一些很有钱而且很有必要的公司在会选择这种方案。大多数还是会选择第3种。
3.软件实现的
HAPROXY 是一个经典代表。他就是在CLIENT 和SERVER中间架了一层LB。 HA 可以RUN在和CLIENT的同一台机器上，也可以RUN在不同的机器上。RUN在同一台机器上，那么直接起一个LOCALHOST，就可以把CLIENT的请求接过来，再转发出去。如果不能再一台机器上，我们就一个代理层在C 和 S之间。
