早期的互联网应用，由于用户流量比较小，业务逻辑也比较简单，往往一个单服务器就能满足负载需求。随着现在互联网的流量越来越大，稍微好一点的系统，访问量就非常大了，并且系统功能也越来越复杂，那么单台服务器就算将性能优化得再好，也不能支撑这么大用户量的访问压力了，这个时候就需要使用多台机器，设计高性能的集群来应对。
那么，多台服务器是如何去均衡流量、如何组成高性能的集群的呢？
此时就需要请出 「负载均衡器」 入场了。
负载均衡（Load Balancer）是指把用户访问的流量，通过「负载均衡器」，根据某种转发的策略，均匀的分发到后端多台服务器上，后端的服务器可以独立的响应和处理请求，从而实现分散负载的效果。负载均衡技术提高了系统的服务能力，增强了应用的可用性。
目前市面上最常见的负载均衡技术方案主要有三种：
基于DNS负载均衡
基于硬件负载均衡
基于软件负载均衡
三种方案各有优劣，DNS负载均衡可以实现在地域上的流量均衡，硬件负载均衡主要用于大型服务器集群中的负载需求，而软件负载均衡大多是基于机器层面的流量均衡。在实际场景中，这三种是可以组合在一起使用。下面来详细讲讲：
基于DNS负载均衡
基于DNS来做负载均衡其实是一种最简单的实现方案，通过在DNS服务器上做一个简单配置即可。
其原理就是当用户访问域名的时候，会先向DNS服务器去解析域名对应的IP地址，这个时候我们可以让DNS服务器根据不同地理位置的用户返回不同的IP。比如南方的用户就返回我们在广州业务服务器的IP，北方的用户来访问的话，我就返回北京业务服务器所在的IP。
在这个模式下，用户就相当于实现了按照「就近原则」将请求分流了，既减轻了单个集群的负载压力，也提升了用户的访问速度。
使用DNS做负载均衡的方案，天然的优势就是配置简单，实现成本非常低，无需额外的开发和维护工作。
但是也有一个明显的缺点是：当配置修改后，生效不及时。这个是由于DNS的特性导致的，DNS一般会有多级缓存，所以当我们修改了DNS配置之后，由于缓存的原因，会导致IP变更不及时，从而影响负载均衡的效果。
另外，使用DNS做负载均衡的话，大多是基于地域或者干脆直接做IP轮询，没有更高级的路由策略，所以这也是DNS方案的局限所在。
基于硬件负载均衡
硬件的负载均衡那就比较牛逼了，比如大名鼎鼎的 F5 Network Big-IP，也就是我们常说的 F5，它是一个网络设备，你可以简单的理解成类似于网络交换机的东西，完全通过硬件来抗压力，性能是非常的好，每秒能处理的请求数达到百万级，即 几百万/秒 的负载，当然价格也就非常非常贵了，十几万到上百万人民币都有。
因为这类设备一般用在大型互联网公司的流量入口最前端，以及政府、国企等不缺钱企业会去使用。一般的中小公司是不舍得用的。
采用 F5 这类硬件做负载均衡的话，主要就是省心省事，买一台就搞定，性能强大，一般的业务不在话下。而且在负载均衡的算法方面还支持很多灵活的策略，同时还具有一些防火墙等安全功能。但是缺点也很明显，一个字：贵。
基于软件负载均衡
软件负载均衡是指使用软件的方式来分发和均衡流量。软件负载均衡，分为7层协议 和 4层协议。
网络协议有七层，基于第四层传输层来做流量分发的方案称为4层负载均衡，例如 LVS，而基于第七层应用层来做流量分发的称为7层负载均衡，例如 Nginx。这两种在性能和灵活性上是有些区别的。
基于4层的负载均衡性能要高一些，一般能达到 几十万/秒 的处理量，而基于7层的负载均衡处理量一般只在 几万/秒 。
基于软件的负载均衡的特点也很明显，便宜。在正常的服务器上部署即可，无需额外采购，就是投入一点技术去优化优化即可，因此这种方式是互联网公司中用得最多的一种方式。
上面讲完了常见的负载均衡技术方案，那么接下来咱们看一下，在实际方案应用中，一般可以使用哪些均衡算法？
轮询策略
负载度策略
响应策略
哈希策略
下面来分别介绍一下这几种均衡算法/策略的特点：
NO1—— Random 随机
这是最简单的一种，使用随机数来决定转发到哪台机器上。
优点：简单使用，不需要额外的配置和算法。
缺点：随机数的特点是在数据量大到一定量时才能保证均衡，所以如果请求量有限的话，可能会达不到均衡负载的要求。
NO2—— Round Robin 轮询
这个也很简单，请求到达后，依次转发，不偏不向。每个服务器的请求数量很平均。
缺点：当集群中服务器硬件配置不同、性能差别大时，无法区别对待。引出下面的算法。
NO3—— Weighted Round Robin 加权轮询
这种算法的出现就是为了解决简单轮询策略中的不足。在实际项目中，经常会遇到这样的情况。
比如有5台机器，两台新买入的性能等各方面都特别好，剩下三台老古董。这时候我们设置一个权重，让新机器接收更多的请求。物尽其用、能者多劳嘛！
这种情况下，“均衡“就比较相对了，也没必要做到百分百的平均。
NO4—— Least Connections 最少连接
这是最符合负载均衡算法的一个。需要记录每个应用服务器正在处理的连接数，然后将新来的请求转发到最少的那台上。
NO5—— Source Hashing 源地址散列
根据请求的来源ip进行hash计算，然后对应到一个服务器上。之后所有来自这个ip的请求都由同一台服务器处理。
>
负载均衡 建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展 网络设备 和 服务器 的带宽、增加 吞吐量 、加强网络数据处理能力、提高网络的灵活性和可用性。
负载均衡，英文名称为 Load Balance，其意思就是分摊到多个 *** 作单元上进行执行，例如 Web 服务器 、 FTP 服务器 、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。
软件负载均衡则是通过在服务器上安装的特定的负载均衡软件或是自带负载均衡模块完成对请求的分配派发。常用的负载均衡策略：
1️⃣轮询
作为非常经典的负载均衡策略，早期该策略应用地非常广泛。其原理很简单，给每个请求标记一个序号，然后将请求依次派发到服务器节点中，适用于 集群 中各个节点提供服务能力等同且无状态的场景。其缺点也非常明显，该策略将节点视为等同，与实际中复杂的环境不符。加权轮询为轮询的一个改进策略，每个节点会有权重属性，但是因为权重的设置难以做到随实际情况变化，仍有一定的不足。
2️⃣随机
与轮询相似，只是不需要对每个请求进行编号，每次随机取一个。同样地，该策略也将后端的每个节点是为等同的。另外同样也有改进的加权随机的算法，不再赘述。
3️⃣最小响应时间
通过记录每次请求所需的时间，得出平均的响应时间，然后根据响应时间选择最小的响应时间。该策略能较好地反应服务器的状态，但是由于是平均响应时间的关系，时间上有些滞后，无法满足快速响应的要求。因此在此基础之上，会有一些改进版本的策略，如只计算最近若干次的平均时间的策略等。
4️⃣最小并发数
客户端的每一次请求在服务器停留的时间可能会有较大的差异，随着工作时间加长，如果采用简单的轮循或随机均衡算法，每一台服务器上的连接进程可能会产生较大的不同，并没有达到真正的负载均衡。最小并发数的策略则是记录了当前时刻，每个备选节点正在处理的事务数，然后选择并发数最小的节点。该策略能够快速地反应服务器的当前状况，较为合理地将负责分配均匀，适用于对当前系统负载较为 敏感的场景 。
F5 负载均衡是硬件负载均衡的一种。硬件负载均衡，顾名思义，在服务器节点之间安装专门的硬件进行负载均衡的工作。
F5 是负载均衡产品的一个品牌，其地位类似于原来诺基亚在手机品牌中的位置。除了 F5 以外，Radware、Array、A10、Cisco、深信服和华夏创新都是负载均衡的牌子，因为 F5 在这类产品中影响最大，所以经常说 F5 负载均衡。
负载均衡设备转发端口转换原理是：我们要使用统一的流量入口来对外提供服务，本质上就是需要一个流量调度器，通过均衡的算法，将用户大量的请求流量均衡地分发到集群中不同的服务器上。这其实就是我们今天要说的负载均衡。
使用负载均衡可以给我们带来的几个好处：
1、提高了系统的整体性能；
2、提高了系统的扩展性；
3、提高了系统的可用性；
负载均衡类型：广义上的负载均衡器大概可以分为 3 类，包括：DNS 方式实现负载均衡、硬件负载均衡、软件负载均衡。
在网络应用中，有时会使用多台服务器提供同一个服务，负载均衡就是把压力平均分配给每台服务器，比如使用DNS负载均衡就是最有效有简单的一个方法，你可以去试试DNSPOD提供的智能解析，他里边就包含负载均衡功能，我很多朋友都在用，很稳定也很强大~ dnspod＊cn负载均衡架构部分转自 58沈剑 [架构师之路]( >
互联网接入系统内的负载均衡系统可以解决并发压力，提高应用处理性能（增加吞吐量，加强网络处理能力）；提供故障转移，实现高可用；通过添加或减少服务器数量，提供网站伸缩性（扩展性）；安全防护（负载均衡设备上做一些过滤，黑白名单等处理）。
实现负载均衡可以从硬件和软件两方面着手，在硬件上我们可以使用F5等负载均衡器，在软件上我们可以使用LVS、Nginx、HaProxy等负载均衡软件。使用硬件性能强悍，使用软件灵活智能。
用户请求数据包，到达负载均衡服务器后，负载均衡服务器在 *** 作系统内核进程获取网络数据包，根据负载均衡算法得到一台真实服务器地址，然后将请求目的地址修改为获得的真实IP地址，不需要经过用户进程处理。 真实服务器处理完成后，响应数据包回到负载均衡服务器，负载均衡服务器，再将数据包源地址修改为自身的IP地址，发送给用户浏览器。
负载均衡的原理
1、利用DNS，通过使用域名解析实现负载均衡
配置多个A 记录，这些A记录对应的服务器构成集群。大型网站总是部分使用DNS解析，作为第一级负载均衡。 显而易见，使用这种方式的负载均衡的控制权在域名商那里，不易拓展，并且用这种方式的负载不能很好的分流，有可能造成所有的请求都集中到一个节点上。不过，若作为第一层的负载均衡的确是个好办法。
2、利用>
当>
理解负载均衡，必须先搞清楚正向代理和反向代理。注：
正向代理，代理的是用户。
反向代理，代理的是服务器
什么是负载均衡
当一台服务器的单位时间内的访问量越大时，服务器压力就越大，大到超过自身承受能力时，服务器就会崩溃。为了避免服务器崩溃，让用户有更好的体验，我们通过负载均衡的方式来分担服务器压力。
我们可以建立很多很多服务器，组成一个服务器集群，当用户访问网站时，先访问一个中间服务器，在让这个中间服务器在服务器集群中选择一个压力较小的服务器，然后将该访问请求引入该服务器。如此以来，用户的每次访问，都会保证服务器集群中的每个服务器压力趋于平衡，分担了服务器压力，避免了服务器崩溃的情况。
负载均衡是用反向代理的原理实现的。
1、轮询（默认）
每个请求 按时间顺序逐一分配 到不同的后端服务器，如果后端服务器down掉，能自动剔除。
upstreambackserver {server192168014;server192168015;}
2、weight
指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的
情况。
upstreambackserver {server192168014weight=3;server192168015weight=7;}
权重越高，在被访问的概率越大，如上例，分别是30%，70%。
3、上述方式存在一个问题就是说，在负载均衡系统中，假如用户在某台服务器上登录了，那么该用户第二次请求的时候，因为我们是负载均衡系统，每次请求都会重新定位到服务器集群中的某一个，那么已经登录某一个服务器的用户再重新定位到另一个服务器，其登录信息将会丢失，这样显然是不妥的。
我们可以采用ip_hash指令解决这个问题，如果客户已经访问了某个服务器，当用户再次访问时，会将该请求通过哈希算法，自动定位到该服务器。
每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。
upstreambackserver{ip_hash;server192168014:88;server192168015:80;}
4、fair（第三方）
按后端服务器的响应时间来分配请求，响应时间短的优先分配。
upstreambackserver {serverserver1;serverserver2;fair;}
5、url_hash（第三方）
按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。
upstream backserver { server squid1:3128; server squid2:3128; hash$request_uri; hash_method crc32;}123456
每个设备的状态设置为:
down 表示单前的server暂时不参与负载
weight 默认为1weight越大，负载的权重就越大。
max_fails：允许请求失败的次数默认为1当超过最大次数时，返回 proxy_next_upstream模块定义的错误
fail_timeout:max_fails次失败后，暂停的时间。
backup： 其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。
配置实例：
#user nobody;worker_processes4;events {# 最大并发数worker_connections1024;}>
1、服务直接返回：这种安装方式负载均衡的LAN口不使用，WAN口与服务器在同一个网络中，互联网的客户端访问负载均衡的虚IP（VIP），虚IP对应负载均衡机的WAN口，负载均衡根据策略将流量分发到服务器上，服务器直接响应客户端的请求。
2、桥接模式：桥接模式配置简单，不改变现有网络。负载均衡的WAN口和LAN口分别连接上行设备和下行服务器。LAN口不需要配置IP（WAN口与LAN口是桥连接），所有的服务器与负载均衡均在同一逻辑网络中。
3、路由模式：路由模式的部署方式，服务器的网关必须设置成负载均衡机的LAN口地址，且与WAN口分署不同的逻辑网络。因此所有返回的流量也都经过负载均衡。这种方式对网络的改动小，能均衡任何下行流量。
扩展资料
负载均衡的算法:
1、随机算法：Random随机，按权重设置随机概率。在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
2、哈希算法：一致性哈希一致性Hash，相同参数的请求总是发到同一提供者。当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
3、URL散列：通过管理客户端请求URL信息的散列，将发送至相同URL的请求转发至同一服务器的算法。
参考资料
百度百科-负载均衡
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）