负载均衡算法有哪些

有效的负载均衡器能够智能地确定给定服务器群中的哪个设备最适合处理传入的数据包。这样做需要编程的算法以一种特定的方式分配负载。

根据负载是分布在网络还是应用程序层,算法有很大的不同。算法选择影响负载分配机制的有效性,从而影响性能和业务连续性。

在这里,我们将讨论网络和应用层负载平衡解决方案中几种广泛使用的算法的优缺点。

网络vs应用层

网络层和应用层算法的不同之处在于它们如何能够分析传入的流量以及它们用于分配流量负载的标准。

网络层算法

网络层负载均衡器面临的主要挑战是对流量流的不可见性,仅限于存储在网络包头中的信息。路由决策必须只基于几个因素—主要是源和目标IP数据。

网络层负载平衡器无法评估传入请求的性质、预期的负载生成以及给定时间内可用的服务器资源。他们需要一定数量的猜测来做出路由决策。

轮循一批服务器被编程成以轮流顺序的方式处理负载。该算法假设每个设备能够处理相同数量的请求,而不能够处理活动连接。
加权轮循——根据每个服务器能够处理的请求的相对数量对服务器进行评级。容量越大,请求越多。
最少的连接——请求被发送到活动连接数量最少的服务器,假设所有的连接都产生相同数量的服务器负载。
加权最小连接——服务器根据其处理能力进行评级。负载是根据服务器的相对容量和每个服务器上的活动连接数来分配的。
源IP散列——在请求中组合源和目标IP地址以生成散列键,然后将其指定给特定的服务器。这允许将删除的连接返回到最初处理它的同一服务器。

应用程序层算法

应用层负载平衡器根据正在处理的请求的内容分发请求,包括除会话cookie之外的HTTP/S头和消息。它们还可以在从服务器返回时跟踪响应,从而提供关于每个服务器在任何时候都在处理的负载的数据。

与网络负载平衡的推测性相反,应用程序负载平衡是数据驱动的。这提供了传入请求的智能分发。

最值得注意的应用层算法是等待请求最少(LPR)。它监视挂起的HTTP/S请求,并将它们分发到最可用的服务器。LPR可以立即调整以适应新连接的突然涌入,同时持续监视服务器场中所有服务器的工作负载。

  • 精确的负载分配——与网络层算法根据预先设定的规则分配请求不同,LPR智能地选择最适合实时处理传入连接的服务器。

  • 请求特定分发—LPR可以确认连接请求占用不同的处理时间,并相应地分配负载。因此,流量不会被路由到繁忙的服务器。

手动删除Apache Kafka topic
window命令行工具推荐:cmder, Babun,Cygwin,terminus
ajax-loader