负载均衡技术原理

参看文章:

快速理解高性能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 就把其从服务器队列中拿出,不参加下一次的用户请求的分配,直到其恢复正常。
  • 4
    点赞
  • 23
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

叨陪鲤

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值