随机二选一负载均衡

面对API网关转发请求到服务节点时的负载均衡问题,文中提出了随机二选一的解决方案。当高并发导致请求集中到某一节点时,通过随机选取两个节点并选择负载较小的一个来减轻抖动。这种方法相比实时更新节点负载信息更简单,且理论分析表明在大规模请求下能有效分散负载。
摘要由CSDN通过智能技术生成

我们有个应用,基本架构是前面有几个API网关,后面有多个有状态的服务节点,用户的操作都是走API网关,API网关把请求转发给客户对应的服务节点。自然我们希望服务节点的负载尽量平均。

因为服务节点都是一样的硬件配置,每个客户的消耗的资源也基本一致,我们直接使用每个服务节点的登录客户数来表示服务节点的负载。

看一下登录的流程:

  1. 客户向API网关发起登录请求
  2. API网关找到负载最小的服务节点(负载信息都保存在一个Redis中)
  3. 向找到的服务节点转发登录请求
  4. 服务节点登录成功,更新负载信息(也就是客户数),登录失败不更新

从API网关查到负载最小的服务节点,到这个节点更新负载信息是有一定时间的(登录耗时),这就导致了高并发的时候,会有大量的请求分到同一个服务节点。

例如有两个节点,负载分别是4和5,这时API网关同时收到10个请求,这10个请求会都分给负载4的节点,然后它的负载变成14。下一波请求来的时候又给会发给5的节点,抖动很大。

怎么解决呢?

方法一是在API网关记录节点负载信息,请求过来马上更新,然后再转发,当然要准确的负载信息还是很麻烦的,例如API网关要知道每个节点登录的客户数,还要处理登录失败的情况。

方法二就是这篇文章标题,随机二选一,即:从全部服务节点中随机选2台,然后选择负载较小的一台作为结果,实现要简单很多。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值