常用负载均衡详解

1 介绍

在互联网场景下,负载均衡(Load Balance)是分布式系统架构设计中必须考虑的一个环节,它通常是指将负载流量(工作任务、访问请求)平衡、分摊到多个操作单元(服务器、组件)上去执行的过程。

目的在于提供负载配比,解决性能、单点故障(高可用)和扩展性(水平伸缩)等问题。

以上图为例,随着互联网的兴盛,类似淘宝、京东等网站的访问量逐年提升。原先的单台服务或者单集群模式已经远不能满足需求了,这时候就需要横向扩展多台服务或者多个集群来分摊压力,达到提升系统吞吐的能力,这就是著名的分治理论。

但服务器增加了,他们之间的流量负载也必须有一个组件来管控,这就是负载均衡的作用。负载均衡提供了多种算法策略来满足不同的业务负载需求,下面我们详细来讲解下。

2 几种常见的负载均衡策略

2.1 轮询(Round Robin)

RR轮询,即Round Robin。按照请求的顺序轮流分配到不同的服务器,循环往复。这种策略适用于服务器性能相近的情况,可以平均分配负载。但如果某个服务器性能较差或者偶发故障,会影响整个系统的性能和稳定性。

如下图所示:

  • 分别有5条请求过来
  • 按照顺序轮流分配,web-server1 分配到 1、4,web-server2 分配到 2、5,web-server3 分配到 3。

2.2 按照权重轮询(Weighted Round Robin)

即加权轮询,给不同的服务器分配不同的权重,根据权重比例来决定分配请求的数量。这种策略适用于后端服务器性能不均的情况,可以根据实际情况灵活调整。使得性能更好的服务器能够处理更多的请求,从而提高整个系统的处理效率。

如下图所示:

  • 分别有5条请求过来
  • web-server1 因为权重为60%,分配到 1、2、3
  • web-server2 权重为20%,分配到 4
  • web-server3 权重为20%,分配到 5

2.3 IP 哈希(IP Hash)

根据客户端的IP地址计算哈希值,将请求分配给特定的服务器,保证相同IP的客户端请求始终发送到同一台服务器。这种策略适用于需要保持客户端会话一致性的场景,例如需要维护用户session的Web应用。

如下图所示:

  • IP为192.168.0.99的流量hash计算对应web-service1,所以将1、4流量分配到第1台服务器
  • IP为192.168.0.96、192.168.0.98的流量hash计算对应web-service3,所以将2、3流量分配到第1台服务器

需要注意的是,虽然IP哈希算法可以确保来自同一IP地址的请求被发送到同一台服务器,这在一些需要保持会话一致性的场景中很有用,但它也可能导致负载不均衡。例如,如果某个IP地址发送了大量的请求,那么处理这些请求的服务器可能会过载,而其他服务器可能处于空闲状态。因此,在使用IP哈希算法时,需要仔细考虑其适用性和潜在的风险。需要对极端情况进行评估,笔者就曾经踩过坑。

2.4 最少连接(Least Connections)

将请求分配给当前连接数最少的服务器,以实现负载均衡。这种策略适用于处理长连接请求的场景,如WebSocket、FTP服务。通过记录每台服务器当前正在处理的连接数,将新请求分配给连接数最少的服务器,可以有效避免某些服务器过载导致性能下降的情况。

如下图所示:

  • web-service1、web-service2、web-service3的连接数分别是11、15、2,所以 web-service3 相对空闲
  • 1、2、3请求到来的时候,web-service3持续空闲,而web-service1、web-service2持续hold住连接,所以请求分配给web-service3
  • 该算法对服务器性能差异较大的情况有较好的适应性,请求优先发送到连接数较少的服务器,有助于避免某些服务器过载,提升性能。
  • 缺少点就是需要实时监测连接数,并且每个流量来的时候都要判断下再分发,在流量繁忙时增加了服务器开销,影响性能。

2.5 最短响应时间(Least Response Time)

短响应时间(Least Response Time)算法在负载均衡领域中被广泛应用。这种策略适用于对响应时间有严格要求的应用场景。通过实时监测每台服务器的响应时间,将请求分配给响应时间最短的服务器,可以确保用户获得最快的响应,提升用户体验。

如下图所示:

同样,这种算法也有自己的优缺点:

优点

1、提高用户体验 :通过选择响应时间最短的服务器来处理请求,可以显著减少用户的等待时间,提高整体的用户体验。

2、动态负载均衡 :该算法能够实时地根据服务器的响应时间来调整负载分配,确保每台服务器都能根据其实际性能来处理相应数量的请求。

3、处理高峰期流量:在流量高峰期,最短响应时间算法可以确保请求被迅速处理,避免系统拥堵和延迟。

缺点

1、计算开销 :为了确定每台服务器的响应时间,系统需要不断地进行监测和计算,这可能会增加额外的系统开销。

2、瞬时波动 :由于该算法主要依赖于实时的响应时间,因此可能会受到瞬时波动的影响。例如,如果某台服务器在某一时刻由于某种原因(如临时的高负载)响应时间变长,它可能会被暂时排除在负载均衡之外,即使其实际性能可能仍然优于其他服务器。

3、可能忽略其他性能指标:最短响应时间算法主要关注响应时间,可能忽略了其他重要的性能指标,如服务器的处理能力、内存占用等。在某些情况下,这可能导致负载分配不够均衡。

3 总结

本文介绍了常见的几种负载均衡策略,此外,还有一些其他策略,如:

  • DNS负载均衡,适用于全球范围内的负载均衡,可以根据用户的地理位置将请求分发到最近的服务器,提高访问速度。
  • 数据层负载均衡,需要考虑"数据与请求均衡的平衡",最常见的方式就是按照分库分表进行分片hash负载

在选择负载均衡策略时,需要根据实际应用场景、服务器性能、网络状况等因素进行综合考虑,以达到最佳的负载均衡效果。

相关推荐
wowocpp16 分钟前
ubuntu 22.04 硬件配置 查看 显卡
linux·运维·ubuntu
萨格拉斯救世主38 分钟前
jenkins使用slave节点进行node打包报错问题处理
运维·jenkins
川石课堂软件测试1 小时前
性能测试|docker容器下搭建JMeter+Grafana+Influxdb监控可视化平台
运维·javascript·深度学习·jmeter·docker·容器·grafana
pk_xz1234562 小时前
Shell 脚本中变量和字符串的入门介绍
linux·运维·服务器
小珑也要变强2 小时前
Linux之sed命令详解
linux·运维·服务器
Lary_Rock5 小时前
RK3576 LINUX RKNN SDK 测试
linux·运维·服务器
一坨阿亮8 小时前
Linux 使用中的问题
linux·运维
wclass-zhengge10 小时前
Docker篇(Docker Compose)
运维·docker·容器
李启柱10 小时前
项目开发流程规范文档
运维·软件构建·个人开发·设计规范
力姆泰克11 小时前
看电动缸是如何提高农机的自动化水平
大数据·运维·服务器·数据库·人工智能·自动化·1024程序员节