自古帝王多短命,假如皇帝也懂负载均衡算法...

假设在一定时期内,阿玛皇帝最珍视的贵妃是凌飞、贤妃、高贵妃和春妃。如何选择常用的轮询算法?

我们首先定义一组嫔妃如下:

然后我们轮询表中的嫔妃,并使用变量索引来记录轮询位置。

输出将不被发布。该算法的特点是简单易行!但是也有很大的缺点!

如果皇帝更加宠爱他的妻子并希望她为她服务呢?然后,您需要使用以下加权轮询算法!

加权轮询算法

加权轮询是为每个妾主观设置一个偏好值(权重值),以控制被选择的概率,所以我们需要定义以下配置:

这里的配置不再是简单的集合,每个妾都有一个权重值。如何在轮询期间根据该值增加被选择的概率?

让我们来谈谈三种常见的实现。

加权轮询实现一

我们的想法是根据权重值将该映射的键(妾)转储到列表中,然后轮询该列表。如果权重值为5,则向列表中添加5条相同的记录!

然后我们浏览这个列表,所以权重值越高,出现在列表中的概率就越高,被轮询的概率就越高!

输出结果如下:

加权轮询算法相对简单,易于实现。然而,也有一个问题。我们配置的权重值是5、1、3和2。我们还可以将它们配置为50、10、30和20吗?

根据上述方法,我们是否需要将数百个相同的元素放入列表中?这显然是不合理的和消耗记忆的!

加权轮询实现两个

基于上述算法中存在的问题,我们考虑使用相似的比例来处理它们。

例如,我们配置的权重值是50、10、30、20,这意味着横坐标为0_____50_60__80__110。

我们仍然使用索引来记录投票位置。如果索引在0和50之间,则意味着选择了第一个妾;如果索引在50和60之间,则意味着选择了第二个妾.

我们看到了具体的代码实现:

输出结果与上面的方法相同:

加权轮询算法比第一个算法稍微复杂一些。然而,这两种实现的共同问题是,根据我们当前的配置,对于妃嫔将连续进行5次轮询,对于精制妃嫔将进行1次轮询,对于高级妃嫔将进行3次轮询.

连续5次!即使阿玛皇帝喜欢再次制造公主,即使是公主也有点过分了!用计算机术语来说,就是说,负载不是很平衡!

加权轮询实现三(平滑加权轮询)

平滑加权轮询算法是为了解决上述负载不平衡的情况,实现起来比较复杂!

每个妾不仅有一个重量,而且有一个动态的重量来帮助计算。

动态权重值的计算逻辑如下:

动态权重值最初为0。

set dynamicweight=dynamicweight每当您进行投票以获得目标公主时。

然后在所有嫔妃中找出最有活力的一个,这也是本次调查的目标。

将这次轮询的目标的动态权重设置为动态权重。

从这个角度来看可能有点不清楚。让我们进行计算,并假设我们仍然具有以下配置(仅妾的名称和配置中相应的重量值):

在上述配置中,总重量值=5 1 3 2等于11。

①根据上述算法的第一点,在第一次轮询目标之前,它们的动态八为0。

因此,四个妃子的权重和动态权重8值如下:

②根据上述算法的第二点,动态权重=第一次轮询选定目标时的动态权重。

更改后,四个妃子的权重和动态八值如下:

③根据上述算法的第三点,然后找到最大的动态八,即5,于是公主在第一次投票中被选中。

④根据上述算法的第四点,公主的动态权重需要从总权重中减去。

更改后,四个妃子的权重和动态八值如下:

然后在第二次轮询期间根据算法的第一点设置动态八值。

设置重量和动力8

通过这种方式,它已经按照算法进行了处理。经过11轮轮询后,所有嫔妃的动态8将再次更改为0.

如果每个人还是有点模糊,我们只能用代码来表示尊敬!我们需要定义一个实体来存储每个公主以及相应的权重和dynamicWeight属性:

然后定义两个全局对象存储对象:

然后实现算法:

最终输出如下:

经过11轮轮询,公主也出现了5次,但显然它不会像以前的算法那样连续出现,它会更加平衡!如果不清楚,可以在文章末尾从Github地址下载代码,自己调试和理解!

随机算法

平滑加权轮询算法可以很好地加载!不过,阿玛皇帝也说,根据投票算法,我可以不带刺激或刺激地把每天晚上在卧室里服务的妃子带出来。

皇帝,我们可以理解我们总是喜欢有一些新鲜的刺激!幸运的是,我们有一个随机算法来解决这个问题。我们每晚随机选择一个,这样皇帝就不能提前推测,也不能给皇帝足够的刺激。

我们仍然定义一组嫔妃如下:

然后使用随机函数选择一个目标:

由于输出是随机的,所以不会发布在这里。如果了解轮询算法,随机算法也很容易理解。只有全局索引用于存储轮询中每个周期的位置,而值是随机生成的。

加权随机算法

加权随机实现一

加权随机实现一与上面的加权轮询实现一的思想几乎相同,所以代码直接应用在这里:

加权随机实现二

加权随机实现二

加权随机实现二与上面的加权轮询实现二的思想几乎相同,所以代码直接应用在这里:

源地址哈希算法

我们工作中开发系统的一个共同要求是在访问之前登录,这将涉及会话!

如果我们不共享会话,登录会话信息将只存在于我们调用登录界面的服务器上!

根据以前的轮询算法或随机算法,来自同一个客户端的多个请求将落在不同的服务器上,这将导致一些接口没有访问权限!

因此,我们需要同一个客户端在同一个服务器上删除多个请求。这里常见的方法是散列源地址!

当我们到达这里时,我们必须让我们的阿玛尔皇帝休息一会儿,回到我们正常的商业环境。如果我们有一个服务器配置如下:

ip被客户端访问,我还模拟了一个集合:

源地址哈希算法的思想是哈希客户端的ip,然后使用哈希值来模拟服务器的数量,以获得要访问的服务器的ip。只要客户端ip保持不变,哈希后的值就会固定!

最终输出如下:

最终输出如下:

这样,无论执行多少次,同一客户端ip请求获得的服务器地址都是相同的!

这种认识很简单,但也很脆弱!因为我们的服务器数量可能会改变,所以今天一台机器离线,明天再多一台机器是很常见的!

一旦服务器数量发生变化,源地址哈希后的模值可能会发生变化,所获得的服务器的ip也会自然发生变化!

例如,我们的服务器删除了一台192.168.4.10机器,然后查看输出:

比较输出结果,我们可以看到影响几乎是全球性的!即使服务器数量发生变化,我们能否制定计划来减少受影响的客户端数量?这需要以下一致的哈希算法!

一致散列算法

加权轮询算法实现2我们讨论了将权重值转换为横坐标以供显示,我们可以在这里使用相同的想法吗?

客户机ip哈希后,它只是一个int32号,然后我们可以将int32号分成几个段,让每个服务器负责一个段的请求!

为了可视化以下内容,我们分别使用ip1、IP2、IP3和IP4来表示服务器192.168.2.10、192.168.2.20、192.168.2.30和192.168.2.40。如上图所示:

如果客户端IP的哈希值在0到之间,将由IP2服务器处理。

如果客户端ip的哈希值在和之间,它将由IP4服务器处理。

如果客户端ip的哈希值大于,它将由IP1服务器处理。

但是专业表达会从横坐标白万形成一个环,这个环被称为哈希环,如下图所示:

让它更直观!如果IP4服务器有一天宕机,所有最初需要转到IP4的请求将被转移到IP1服务器进行处理。

这仍然会影响一些客户的请求,但至少影响是部分的,如下图所示:

这样可以吗?我们考虑两个问题:“散列环上每个服务器的位置由我们人工平均分配。当经常需要扩大或缩小产能时,是否难以维持?

IP4关闭,对IP4的请求全部转移到IP1。这会导致IP1流量不均衡吗?有没有更平衡的计划将原始流量转移到IP4到IP1、IP2和IP3?

问题1的解决方案不是手动分配节点的位置,而是根据服务器的ip计算哈希值,然后查看哈希值在环上的位置!

这样做的一个问题是每个集群中服务器的ip不同,所以计算后环上的位置可能无法控制。

如下图所示,上述四个服务器的位置可能如下:

显然,这种情况极不均衡,会导致数据倾斜!上面问题2中的问题实际上是停机造成的数据偏斜!

环的左上角是空的,我们能根据当前4台服务器的其他规则在左上角生成一些节点吗?这是否意味着请求会稍微统一一些?

这就是所谓的虚拟节点!虚拟节点是根据特定规则生成多个hashcode的同一个服务器ip,因此环上有多个节点。

如下图所示:

这只是模拟每台服务器有两个虚拟节点,实际开发中还会有更多!这样,即使IP4机器挂起,请求也不会全部被压到一个服务器上!

说了这么多,实施起来并不难。下面是代码(服务器配置和请求的客户端ip与源地址哈希算法一致,所以相应的代码不粘贴在这里,算法逻辑直接应用):

这里介绍了几种常用的负载均衡算法和代码实现!尚不清楚您能否从同性约会网络下载样本代码并自行调试:

Author:苏静

Introduction:在大型互联网项目中有多年的开发经验,在高度并发、分布式和微服务技术方面有深入研究和相关实践经验。有经验的自学,热衷于技术研究和分享!座右铭:永远虚心学习!回到搜狐看更多

——