算法

轮询与加权轮询

轮询：所有的候选节点轮流作为负载均衡的目标节点。

加权轮询：根据权重轮流。

随机可以看作是随便挑选一个作为目标节点。

加权随机则是利用不同的权重来设置选中的概率。权重越大，那么被选中的机会也就越大。

哈希算法比较简单，一般就是选取请求里面某几个参数来计算一个哈希值，然后除以节点数量取余。

一致性哈希负载均衡引入了一个哈希环的概念，服务端节点会落在环的某些位置上。客户端根据请求参数，计算一个哈希值。这个哈希值会落在哈希环的某个位置。从这个位置出发，顺时针查找，遇到的第一个服务端节点就是目标节点。

在做负载均衡的时候就是看一下客户端和各个节点的连接数量，从中挑选出连接数数量最少的节点。

最少连接数算法的缺陷在于，连接数并不能代表节点的实际负载。

所谓的活跃请求，就是已经接收但是还没有返回的请求。

客户端会维持一个自己发过去但是还没返回的请求数量，然后每次挑选活跃请求最少的那个服务端节点。

活跃请求数量也不能真正代表服务端节点的负载。

用的是响应时间来代表服务端节点的负载。

最快响应时间算法就是客户端维持每个节点的响应时间，而后每次挑选响应时间最短的。

一般来说统计响应时间时应该只用近期请求的响应时间，并且越近的响应时间，权重应该越高。换句话说，就是采集的响应时间效用应该随着时间衰减。

让服务端上报指标，而不是客户端采集。总体上有两种思路。

第一种思路是服务端在返回响应的时候顺便把服务端上的一些信息一并返回。这种思路需要微服务框架支持从服务端往客户端回传链路元数据。

第二种思路是从观测平台上查询。例如通过查询 Prometheus 来获得各种指标数据。

不过目前业界很少用这种复杂的负载均衡算法，也因此几乎所有的微服务框架都没有服务端上报指标到客户端的机制。

在工作中我们可以考虑根据调用结果来动态调整这个权重。

关键词成加败减。

如果调用成功了，那么就增加权重；如果调用失败了，那么就减少权重。

权重的调整要设置好上限和下限。

调整权重的算法都要考虑安全问题，即权重的调整应该有上限和下限。比如说一般下限不能为 0，因为一个节点的权重为 0 的话，它可能永远也不会被选中，又或者和 0 的数学运算会出现问题导致负载均衡失败。上限一般不超过初始权重的几倍，比如说两倍或者三倍，防止该节点一直被连续选中。

此文章为9月Day22学习笔记，内容来源于极客时间《后端工程师的高阶面经》