前言：

最近在公司部署了一个简易的负载均衡集群，这个集群的主要功能是分摊公司业务服务器的流量，防止服务器因为访问量过大而造成负，导致服务宕机或者响应速度慢等一系列问题。在这里做个简要的记录，方便后续自己复盘，也给感兴趣的读者学习学习，如果存在问题帮忙指正哈。
学习了这系列的文章你将会自己搭建简单的负载均衡集群，了解负载均衡集群在高访问量的情况下充当的重要角色，可以有效的保护业务服务器稳定运行。

了解负载均衡：

负载均衡建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。我这里就不做过多介绍了，我就拿我自己搭建的集群给看官说明一下哈：

说明： 从图中的三个部分：用户，负载均衡服务器，业务服务器分别来分析：

• 用户：用户发送请求（这里可以理解为大量的用户发送大量的请求）。

• 负载均衡服务器：必须有公网IP才可以对外开放，绑定开放端口，与业务服务器建立独立的通信通道。

• 业务服务器：把业务端口映射到负载均衡服务器上，部署业务流程。

• 整体的流程大概就是：用户发送请求，访问负载均衡服务器，通过HAProxy的负载均衡算法把流量分摊到压力最小的业务服务器上，业务服务器响应请，原路返回响应内容到达用户端。整个过程中我们可以想象一下，大量访问到达负载均衡服务器，经负载均衡算法把每个访问分摊到压力最小的业务服务器上，从而保护了业务服务器，大大减轻了业务服务器的压力。

• 举个程序员最能感受到的例子：你们小组有8个程序员（业务服务器）和一个组长（负载均衡），当产品（用户）的若干需求出来的时候是不是要程序员去实现，如果只有8个程序员去实现的话，但是产品跟1号程序员比较熟悉，然后他就把所有的需求都给了1号去实现，其他程序员非常空闲，1号程序员可能得天天加班然后还得一个月完成这些需求，造成得结果会是什么？需求完成的慢，程序员因为长期高强度工作心里有了负面情绪，离职了（宕机），这种情况是非常糟糕的！于是改变了工作方式，产品把这些需求统一交给了组长，组长是不是每天都有8个程序员的工作汇报，了解他们手上的工作，于是经过组长的调节，把这些需求相对平均的分配到8个程序员身上，这样达到的效果是8个程序员的工作量相对平均，他们可以每天不用加班而且10天就完成了所有的需求，这样需求的完成速度加快了，而且程序员也轻松，这样的情况是公司最愿意看到的！

负载均衡算法：

轮询：

• 将所有请求，依次分发到每台服务器上，适合服务器硬件同相同的场景。
  优点：服务器请求数目相同；
  缺点：服务器压力不一样，不适合服务器配置不同的情况；

随机：

• 请求随机分配到各个服务器。
  优点：使用简单；
  缺点：不适合机器配置不同的场景；

最少链接：

• 将请求分配到连接数最少的服务器（目前处理请求最少的服务器）。
  优点：根据服务器当前的请求处理情况，动态分配；
  缺点：算法实现相对复杂，需要监控服务器请求连接数；

Hash（源地址散列）:

• 根据IP地址进行Hash计算，得到IP地址。
  优点：将来自同一IP地址的请求，同一会话期内，转发到相同的服务器；实现会话粘滞。
  缺点：目标服务器宕机后，会话会丢失；

加权:

• 在轮询，随机，最少链接，Hash等算法的基础上，通过加权的方式，进行负载服务器分配。
  优点：根据权重，调节转发服务器的请求数目；
  缺点：使用相对复杂；

总体的算法就是这些了，当然以上可以进行组合使用比较灵活，我网上找了一圈好像8种常用的方法。

负载均衡支持的协议：

• HTTP
• HTTPS
• TCP

总结

以上就是我对负载均衡的简单了解，因为我接触的不是很深，理解不到位的或者有异议的，大家可以给我纠正下哈。其实我觉得这篇文章很生动形象，大家觉得我解释的不是很好理解可以看一下戳我看有趣的文章
后续我会给大家带来详细的搭建过程：

• FRP部署流程实现内网穿透（windows）
• Windows使用cygwin编译haproxy
• HAProxy配置和使用