负载均衡技术原理

参看文章：

快速理解高性能HTTP服务端的负载均衡技术原理

简介几种负载均衡原理

浅谈几种常用负载均衡架构

一篇读懂分布式架构下的负载均衡技术：分类、原理、算法、常见方案等

---

一、 引言

负载均衡（Load Balance）是指将负载(工作任务)进行平衡、分摊到多个操作单元上运行，促使多台设备共同更快、更高效完成某一项或者多项任务。负载均衡在现有网络结构基础上，提供了一种透明并且廉价有效的方法扩展服务器和网络设备的带宽、加强网络数据处理能力，增加吞吐量、提高网络的可用性和灵活性。

负载均衡包含两方面的含义：

• ①将一个复杂任务拆分成多个子任务，然后交由多个操作单元协作处理，最后共同完成这项任务。是不是有点像分布式计算呢？
• ②将海量、高并发访问处理均分到多个处理单元中，雨露均沾，避免旱的旱死，涝的涝死。

为什么要负载均衡？

在网站创立之初，一般只需要一台服务器(通常为LAMP架构作为解决方案)对外提供服务即可，但是随着业务快速扩大，原先的架构依然无法满足现在的业务需求。此时就需要对服务器进行扩容，简单的说就是将多台服务器组成一个集群共同对外提供服务(架构一步到位了)，通过负载均衡技术将用户的请求分流到不同的服务器上，从而达到扩容的目的，这便是负载均衡存在的意义。

目前，负载均衡技术已经广泛地应用在网络之中。就拿全国人民都知晓的“双11购物节”而言，每一秒的订单量都是巨大的，只通过几台服务器完全无法满足这么多人同时访问。各个互联网巨头(淘宝、京东、微信、支付宝、抖音、美团等等)都是通过各种各样的技术来解决这么高的并发访问、海量数据存储等等，他们在满足自己业务需求的同时，将自己的解决方案通过搭建云平台来出售，供其他的小公司使用，从而降低小公司的运营成本(无需从头开始，一步一步来摸索高并发架构解决方案)。

这些解决方案现在基本都是利用集群技术，达到最佳的资源使用、最大化吞吐率、最短的响应时间，避免单点过载问题。集群技术的使用，不可避免的会用到负载均衡技术，否则便无法发挥集群技术的优势。下面负载均衡技术做一个详细的介绍。

二、 负载均衡实现分类

负载均衡实现目前可以分为3类：

基于DNS负载均衡
基于硬件的负载均衡	比如F5
基于软件的负载均衡	比如LVS, NGINX,Squid

原理：当用户访问域名的时候（如www.taobao.com），会先向DNS服务器去解析域名对应的IP地址，这个时候我们可以让DNS服务器根据不同地理位置的用户返回不同的IP。比如杭州的用户就返回淘宝在杭州业务服务器的IP，北京的用户来访问的话，就返回淘宝在北京业务服务器所在的IP。

 

 

在这个模式下，用户就相当于实现了按照「就近原则」将请求分流了，既减轻了单个集群的负载压力，也提升了用户的访问速度。

使用DNS做负载均衡的方案，天然的优势就是配置简单，实现成本非常低，无需额外的开发和维护工作。

但是它也有一个明显的缺点：当配置修改后，生效不及时。这个是由于DNS的特性导致的，DNS一般会有多级缓存，所以当我们修改了DNS配置之后，由于缓存的原因，会导致IP变更不及时，从而影响负载均衡的效果。

另外，使用DNS做负载均衡的话，大多是基于地域或者干脆直接做IP轮询，没有更高级的路由策略，所以这也是DNS方案的局限所在。

有专门的硬件加持，可能比用软件处理要高效。在硬件负载均衡器中，最出名的就是F5负载均衡器：

硬件负载均衡器特点只有一个：除了贵，什么都好。就这一个特点就导致它的市场没有那个普及，因此更多中小公司使用了软件的负载均衡技术。

软件技术的负载均衡，基于OSI 网络模型来实现。我们通过OSI 7层模型来简单说明存在的负载均衡技术。

软件负载均衡分类：

• 二层负载均衡

负载均衡服务器对外提供一个公网IP, 集群中的真正服务器使用相同的内网IP地址，但是MAC地址不同。当负载均衡服务器收到客户请求时，通过修改报文中的目的MAC地址，将报文分流到不同的设备上，从而达到负载均衡的目的。此技术好像不常用。

• ​​​​​​​三层负载均衡

负载均衡服务器对外提供一个公网IP, 集群中的真正服务器使用不同的内网IP地址。当负载均衡服务器收到客户请求时，通过修改报文中的目的IP地址，将报文分流到不同的设备上，从而达到负载均衡的目的。

• ​​​​​​​四层负载均衡

四层负载均衡服务器除了使用传输层(TCP\UDP协议)的端口信息外，也会结合IP层源目的IP地址进行处理。当负载均衡服务器收到客户请求时，通过修改报文中的IP和端口，将报文分流到不同的设备上，从而达到负载均衡的目的。

• LVS
• NAT
• IP隧道

• ​​​​​​​七层负载均衡

七层负载均衡工作在OSI模型的应用层，应用层的协议类型比较多(可以参考上图)，可以通过应用层协议进行分流，同时也可以根据报文中的内容（如URL、浏览器类型、语言、甚至地址位置等）进行负载均衡。

• Nginx负载均衡

其中软件中最常用的就是Nginx负载均衡（7层）和LVS负载均衡（4层）。

基于四层的负载均衡效率要高，一般能达到每秒几十万的处理量；而基于7层的负载均衡处理量一般在每秒几万。

基于软件的负载均衡特点很明显：便宜呀！！！。中小公司可以直接基于开源代码做移植、适配即可，且可以部署在普通服务器上，在研发成本和硬件上大大降低了成本，从而得到了很多公司的使用。

 

三、 负载均衡算法

主要的均衡算法有：

负载均衡算法可以分为两类：静态负载均衡算法和动态负载均衡算法。

• 静态负载均衡算法包括：轮询、比率、优先权。
• 动态负载均衡算法包括：最少连接数、最快响应速度、观察方法、预测法、动态性能分配、动态服务器补充、服务质量、服务类型、规则模式。

---

• 轮询(Round Robin)：顺序循环将请求一次顺序循环地连接每个服务器。当其中某个服务器发生第二到第 7 层的故障，BIG-IP 就把其从顺序循环队列中拿出，不参加下一次的轮询，直到其恢复正常。

实现时，一般为服务器带上权重;这样有两个好处：针对服务器的性能差异可分配不同的负载;当需要将某个结点剔除时，只需要将其权重设置为0即可;

• 优点：实现简单、高效;易水平扩展
• 缺点：请求到目的结点的不确定，造成其无法适用于有写的场景(缓存，数据库写)
• 应用场景：数据库或应用服务层中只有读的场景

• 随机方式：请求随机分布到各个结点;在数据足够大的场景能达到一个均衡分布;
  • 优点：实现简单、易水平扩展
  • 缺点：同 Round Robin，无法用于有写的场景
  • 应用场景：数据库负载均衡，也是只有读的场景
• 哈希方式：根据 key 来计算需要落在的结点上，可以保证一个同一个键一定落在相同的服务器上;
  • 优点：相同 key 一定落在同一个结点上，这样就可用于有写有读的缓存场景
  • 缺点：在某个结点故障后，会导致哈希键重新分布，扩展性较差。
  • 解决：一致性哈希 or 使用 keepalived 保证任何一个结点的高可用性，故障后会有其它结点顶上来
  • 应用场景：缓存，有读有写
• 一致性哈希：在服务器一个结点出现故障时，受影响的只有这个结点上的 key，最大程度的保证正确率;如 twemproxy 中的 ketama方案;生产实现中还可以规划指定子 key 哈希，从而保证局部相似特征的键能分布在同一个服务器上;
• 根据键的范围来负载：根据键的范围来负载，前 1 亿个键都存放到第一个服务器，1~2 亿在第二个结点。
  • 优点：水平扩展容易，存储不够用时，加服务器存放后续新增数据
  • 缺点：负载不均;数据库的分布不均衡;
  • (数据有冷热区分，一般最近注册的用户更加活跃，这样造成后续的服务器非常繁忙，而前期的结点空闲很多)
  • 适用场景：数据库分片负载均衡
• 根据键对服务器结点数取模来负载：根据键对服务器结点数取模来负载;比如有 4 台服务器，key 取模为 0 的落在第一个结点，1 落在第二个结点上。
  • 优点：数据冷热分布均衡，数据库结点负载均衡分布;
  • 缺点：水平扩展较难;
  • 适用场景：数据库分片负载均衡
• 纯动态结点负载均衡：根据 CPU、IO、网络的处理能力来决策接下来的请求如何调度。
  • 优点：充分利用服务器的资源，保证个结点上负载处理均衡
  • 缺点：实现起来复杂，真实使用较少
• 比率(Ratio)：给每个服务器分配一个加权值为比例，根椐这个比例，把用户的请求分配到每个服务器。当其中某个服务器发生第 2 到第 7 层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。
• 优先权(Priority)：给所有服务器分组，给每个组定义优先权，BIG-IP 用户的请求，分配给优先级高的服务器组(在同一组内，采用轮询或比率算法，分配用户的请求);当高优先级中所有服务器出现故障，BIG-IP 才将请求送给次优先级的服务器组。这种方式，实际为用户提供一种热备份的方式。
• 最少的连接方式(Least Connection)：传递新的连接给那些进行最少连接处理的服务器。当其中某个服务器发生第 2 到第 7 层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。
• 最快模式(Fastest)：传递连接给那些响应最快的服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。