负载均衡算法 分手后的思念是犯贱 2022-09-06 15:21 134阅读 0赞 ### 文章目录 ### * 1、简介 * 2、常用的负载均衡算法 * * 2.1 轮询法 * 2.2 加权轮询法 * 2.3 随机法 * 2.4 加权随机法 * 2.5 源地址哈希法 * 2.6 一致性哈希法 # 1、简介 # 服务消费者从服务配置中心获取服务的地址列表后需要选取其中一台发起RPC/HTTP调用,这时需要用到具体的负载均衡算法。常用的负载均衡算法有轮询法、加权轮询法、随机法、加权随机法、源地址哈希法、一致性哈希法等。 # 2、常用的负载均衡算法 # ## 2.1 轮询法 ## 轮询法是将请求按顺序轮流分配到后端服务器上,均衡地对待后端的每一台服务器,不关心服务器实际的连接数和当前系统负载。 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNzUzNzI0_size_16_color_FFFFFF_t_70] 上图中,有9个客户端请求、3台后端服务器。当地一个请求到达负载均衡服务器时,负载均衡服务器会将这个请求分配到后端服务器是;当第二个请求到来时,负载均衡服务器会将这个请求分配到后端服务器2;以此类推。 ## 2.2 加权轮询法 ## 加权轮询法是根据真实服务器的不同处理了能力来调度访问请求,这样可以保证处理能力强的服务器处理更多的访问流量。简单的轮询法并不考虑后端机器的性能和负载差异。加权轮询法可以很大地处理这一问题,它将按照顺序并且按照权重分派给后端服务器:给性能高、负载低的机器配置较高的权重,让其处理更多的请求;给性能低、负载高的机器配置较低的权重,让其处理较少的请求。 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNzUzNzI0_size_16_color_FFFFFF_t_70 1] 假设有9个客户端请求、3台后端服务器如上图所示,后端服务器1被赋予权值1,后端服务器2被赋予权值2,后端服务器3被赋予权值3.这样一来,客户端请求1、2、3都被分派到服务器3处理,客户端请求4、5被分派到服务器2处理,客户端请求6被分派到服务器1处理,客户端请求7、8、9被分派到服务器3处理,以此类推。 ## 2.3 随机法 ## 随机法也很简单,就是随机选择一台后端服务器进行请求处理。由于每次服务器被挑中的概率都一样,因此客户端的请求可以被均匀地分派到所有的后端服务器上。由概率统计理论可以得知,随着调用量的增大,其实际效果越来越接近于平均分配流量到每一台后端服务器,也就是轮询的效果。 ## 2.4 加权随机法 ## 加权随机法跟加权轮询法类似,根据后台服务器不同的配置和负载情况配置不同的权重。不同的是,它是按照权重来随机选取服务器的,而非顺序。加权随机算法一般应用的场景是在一个集合S\{A,B,C,D\}中随机抽取一项,但是抽取的概率不同,比如希望抽到A的概率是50%、抽到B和C的概率是20%、抽到D的概率是10%。一般来说,我们可以给各项附加一个权重,抽取的概率正比于这个权重,上述集合就成了\{A:5,B:2,C:3,D:1\}。扩展这个集合,使每一项出现的次数与其权重正相关,即\{A,A,A,A,A,B,B,C,C,D\},然后就可以用均匀随机算法从中选择取了。 ## 2.5 源地址哈希法 ## 源地址哈希(Hash)是根据获取客户端的IP地址,通过哈希函数计算得到一个数值,用改数值对服务器列表的大小进行取模运算,得到的结果便是客户端要访问服务器的序号。采用源地址哈希法进行负载均衡,当后端服务器列表不变时,同一个IP地址的客户端,每次都会映射到同一台后端服务器进行访问。源地址哈希法的缺点是:当后端服务器增加或减少时,采用简单的哈希取模方法会使命中率大大降低。这个问题可以采用一致性哈希法来解决。 ## 2.6 一致性哈希法 ## 一致性哈希(Hash)法解决了分布式环境下机器增加或者减少时简单的取模运算无法获取较高命中率的问题。通过虚拟节点的使用,一致性哈希算法可以均匀分配机器的负载,使得这一算法更具现实意义。正因如此,一致性哈希算法被广泛应用于分布式系统中。 一致性哈希算法通过**哈希环**的数据结构实现,环的起点是0,终点是 2 32 − 1 2^\{32\}-1 232−1,并且起点与终点点列。哈希环中间的整数按逆时针分布,故哈希环的整数分布范围 \[ 0 , 2 32 − 1 \] \[0,2^\{32\}-1\] \[0,232−1\],具体如下图所示 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNzUzNzI0_size_16_color_FFFFFF_t_70 2] 在负载均衡中,首先为每一台机器计算一个哈希值,然后把这些哈希值放置在哈希环上。假设有3台web服务器s1、s2、s3,它们计算得到的哈希值分别为h1、h2、h3,在哈希环上的位置如下图所示。 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNzUzNzI0_size_16_color_FFFFFF_t_70 3] 计算每一个请求IP的哈希值:hash(“192.168.0.1”),并把这些哈希值放置到哈希环上。假设有5个请求,对应的哈希值为q1、q2、q3、q4、q5,放置到哈希环上如下图所示。 ![请求分布哈希环][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNzUzNzI0_size_16_color_FFFFFF_t_70 4] 接下来为每一个请求找到对应的机器,在哈希环上顺时针查找距离这个请求的哈希值最近的机器,结果如下图所示。 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNzUzNzI0_size_16_color_FFFFFF_t_70 5] 对于线上的业务,增加或减少一台机器的部署上常有的事情。增加服务器s4的部署并将机器s4加入哈希环的机器s3和s2之间。这时,只有机器s3和s4之间的请求需要重新分配新的机器。只有请求q4被重新分配到了s4上,其他请求仍在原有机器上,如下图所示。 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNzUzNzI0_size_16_color_FFFFFF_t_70 6] 从上图的分析可以知道,增减机器只会影响相邻的机器,这就导致了添加机器时只会分担其中一台的负载、删除机器时会把负载全部转移到相邻的一台机器上,这并不是我们希望看到的。我们希望看到的是:增加机器时,新的机器可以合理地分担所有机器地负载;删除机器时,多出来地负载可以均匀地分给剩余地机器。 例如,系统中只有两台服务器,由于某种原因下线NodeB(节点B),此时必然造成大量数据集中安东NodeA(节点A)上,而只有极少量会定位到NodeB上。为此我们引入虚拟节点来解决负载不均衡地问题。可以在服务器IP或主机名地后面增加编号来实现,例如为每台服务器计算3个虚拟节点,分别计算“NodeA\#1”“NodeA\#2”“NodeA\#3”“NodeB\#1”“NodeB\#2”“NodeB\#3”的哈希值,形成6个虚拟节点。同时数据定位算法不变,只是多了一步虚拟节点到实际节点的映射,例如定位到“NodeA\#1”“NodeA\#2”“NodeA\#3”三个虚拟节点的数据均定位到NodeA上。这样就解决了服务节点少时数据倾斜的问题。在实际应用中,通常将虚拟节点数量设置为32甚至更大,因此即使很少的服务节点也能做到相对均匀的数据分布。 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNzUzNzI0_size_16_color_FFFFFF_t_70 7] [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNzUzNzI0_size_16_color_FFFFFF_t_70]: /images/20220829/54ddfbe114364460ac02de918d5e1385.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNzUzNzI0_size_16_color_FFFFFF_t_70 1]: /images/20220829/4fc98052196144acae7bf4da204cbde3.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNzUzNzI0_size_16_color_FFFFFF_t_70 2]: /images/20220829/20a95b7ff8274087b79a6a3ee2c0c0f8.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNzUzNzI0_size_16_color_FFFFFF_t_70 3]: /images/20220829/0f68a7fd0952479080b40ea6fa32422e.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNzUzNzI0_size_16_color_FFFFFF_t_70 4]: /images/20220829/e315658924e943d7a9cdfee1437874ed.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNzUzNzI0_size_16_color_FFFFFF_t_70 5]: /images/20220829/fa9cbbd9458242e6ad1bf5fd0b1d01e3.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNzUzNzI0_size_16_color_FFFFFF_t_70 6]: /images/20220829/4d4914f1073942a98cc506d489a43952.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNzUzNzI0_size_16_color_FFFFFF_t_70 7]: /images/20220829/4891ae75589f46b4920d40f7802f3cd2.png
还没有评论,来说两句吧...