轮询负载均衡算法:RR ,Round Robin,挨个发,适合于所有服务器硬件都相同的场景。一个一个来,如果有两个服务器,第一次是你,第二次就是我。
代码实现:用i 保存 取 服务器的 下标。第一次来 取0,第二次来取1 ,第三次来 取 0。
加权轮询算法:weighted round robin ,wrr,按照权重不同来分发,基本上是基于配置。
代码实现:
比如:两个服务权重分别是6和4,我们的方法,在1-10之间取 随机数,比如取到 1-6,就走6的权重,取到7-10,就走4权重的服务。
随机轮询算法:Random
代码实现:这个就随意了。
最少链接:Least connections,记录每个服务器正在处理的 连接数 (请求数),将新的请求 分发到最少连接的服务器上,这是最符合负载均衡的算法
代码实现:放到redis里,做个hash。
可以用:incr。
(redis> SET key 20
OK
redis> INCR key(integer) 21
redis> GET key # 数字值在 Redis 中以字符串的形式保存"21"
)
每次调用一次,服务次数+1。
原地址散列:Source Hashing,根据请求来源的ip地址 进行hash计算,只要原地址不变,每次请求映射来的后面提供服务的节点也不变。这有利于进行session信息的维护。
计数器(固定窗口)算法
计数器算法,是指在指定的时间周期内,累加访问的次数,达到设定的阈值时,触发限流策略。下一个时间周期进行访问时,访问次数清零。此算法无论在单机还是分布式环境下实现都非常简单,使用redis的incr原子自增性,再结合key的过期时间,即可轻松实现,计算器算法如图所示。
从上图看出,设置一分钟的阈值是100,在0:00到1:00内请求数是60,当到1:00时,请求数清零,从0开始计算,这时在1:00到2:00之间能处理的最大的请求为100,超过100个的请求,系统都拒绝。
这个算法有一个临界问题,例如在图中,在0:00到1:00内,只在0:50有60个请求,而在1:00到2:00之间,只在1:10有60个请求,虽然在两个一分钟的时间内,都没有超过100个请求,但是在0:50到1:10这20秒内,确有120个请求,虽然在每个周期内,都没超过阈值,但是在这20秒内,已经远远超过了原来设置的1分钟内100个请求的阈值。
滑动窗口算法
为了解决计数器算法的临界值的问题,发明了滑动窗口算法。在TCP网络通信协议中,就采用滑动时间窗口算法来解决网络拥堵问题。
滑动时间窗口是将计数器算法中的时间周期切分成多个小的时间窗口,分别在每个小的时间窗口中记录访问次数,然后根据时间将窗口往前滑动并删除过期的小时间窗口。最终只需要统计滑动窗口范围内的小时间窗口的总的请求数即可,如图所示。
在图中,假设设置一分钟的请求阈值是100,将一分钟拆分成4个小时间窗口,这样,在每个小的时间窗口内,只能处理25个请求,用虚线方框表示滑动时间窗口,当前窗口的大小是2,也就是在窗口内最多能处理50个请求。随着时间的推移,滑动窗口也随着时间往前移动,例如图开始时,窗口是0:00到0:30的这个范围,过了15秒后,窗口是0:15到0:45的这个范围,窗口中的请求重新清零,这样就很好的解决了计数器算法的临界值问题。
在滑动时间窗口算法中,小窗口划分的越多,滑动窗口的滚动就越平滑,限流的统计就会越精确。
漏桶算法
漏桶算法的原理就像它的名字一样,维持一个漏斗,它有恒定的流出速度,不管水流流入的速度有多快,漏斗出水的速度始终保持不变,类似于消息中间件,不管消息的生产者请求量有多大,消息的处理能力取决于消费者。
漏桶的容量=漏桶的流出速度*可接受的等待时长。在这个容量范围内的请求可以排队等待系统的处理,超过这个容量的请求,才会被抛弃。
在漏桶限流算法中,存在下面几种情况。
(1)当请求速度大于漏桶的流出速度时,也就是请求量大于当前服务所能处理的最大极限值时,触发限流策略。
(2)请求速度小于或等于漏桶的流出速度时,也就是服务的处理能力大于或等于请求量时,正常执行。
漏桶算法有一个缺点,当系统在短时间内有突发的大流量时,漏桶算法处理不了。
令牌桶算法
令牌桶算法,是增加一个大小固定的容器,也就是令牌桶,系统以恒定的速率向令牌桶中放入令牌,如果有客户端来请求,先需要从令牌桶中拿一个令牌,拿到令牌,才有资格访问系统,这时令牌桶中少一个令牌。当令牌桶满的时候,再向令牌桶生成令牌时,令牌会被抛弃。
在令牌桶算法中,存在以下几种情况。
(1)请求速度大于令牌的生成速度:那么令牌桶中的令牌会被取完,后续再进来的请求,由于拿不到令牌,会被限流。
(2)请求速度等于令牌的生成速度:那么此时系统处于平稳状态。
(3)请求速度小于令牌的生成速度:那么此时系统的访问量远远低于系统的并发能力,请求可以被正常处理。
令牌桶算法,由于有一个桶的存在,可以处理短时间大流量的场景。