在⾼并发访问下,⽐如电商大促活动,流量持续不断的涌⼊,服务之间的相互调⽤频率突然增加,引发系统负载过⾼,这时系统所依赖的服务的稳定性对系统的影响⾮常⼤,⽽且还有很多不确定因素引起雪崩,如⽹络连接中断,服务宕机等。⼀般微服务容错组件提供了限流、隔离、降级、熔断等⼿段,可以有效保护我们的微服务系统。本文主要说说限流。
限流,就是限制最⼤流量,防止操作频率超过定义的限制。系统能提供的最⼤并发有限,同时请求⼜太多,这就就需要限流,⽐如秒杀、大促活动业务,瞬时⼤量请求涌⼊,服务器服务不过来,就只好限流了。速率限制通过限制在给定时间段内可以到达 API 的请求数量来保护服务免受意外或恶意过度使用。在没有速率限制的情况下,任何用户都可以用请求轰炸您的服务器,从而导致其他用户饿死的情况。
下面介绍下四种常⻅的限流算法。
漏桶算法的思路,是一种简单直观的算法,就是⼀个固定容量的漏桶,按照常量固定速率流出⽔滴。如果桶是空的,则不需流出⽔滴。可以以任意速率流⼊⽔滴到漏桶。如果流⼊⽔滴超出了桶的容量,则流⼊的⽔滴溢出了(被丢弃),而漏桶容量是不变的。
这种算法的优点是它可以平滑请求的突发并以恒定的速率处理它们。它也很容易在负载均衡器上实现,并且对每个用户来说都是高效的内存。无论请求的数量如何,都保持到服务器的恒定接近均匀的流量。
缺点是请求的爆发可能会填满存储桶,导致新请求的匮乏。它也不能保证请求在给定的时间内完成。
优点:
缺点:
令牌桶算法:假设限制2r/s,则按照500毫秒的固定速率往桶中添加令牌。桶中最多存放b个令牌,当桶满时,新添加的令牌被丢弃或拒绝。当⼀个n个字节⼤⼩的数据包到达,将从桶中删除n个令牌,接着数据包被发送到⽹络上。如果桶中的令牌不⾜n个,则不会删除令牌,且该数据包将被限流(要么丢弃,要么缓冲区等待)。令牌桶限流原理,如图所示。
令牌桶限流服务器端可以根据实际服务性能和时间段改变⽣成令牌的速度和⽔桶的容量。 ⼀旦需要提⾼速率,则按需提⾼放⼊桶中的令牌的速率。
生成令牌的速度是恒定的,⽽请求去拿令牌是没有速度限制的。这意味着当⾯对瞬时⼤流量,该算法可以在短时间内请求拿到⼤量令牌,⽽且拿令牌的过程并不是消耗很⼤。
每次新请求到达服务器时,都会发生两个操作:
该算法具有内存效率,因为我们为我们的应用程序为每个用户节省了更少的数据量。这里的问题是它可能导致分布式环境中的竞争条件。当来自两个不同应用程序服务器的两个请求同时尝试获取令牌时,就会发生这种情况。
优点:
缺点:
在固定的时间窗⼝内,可以允许固定数量的请求进⼊。超过数量就拒绝或者排队,等下⼀个时间段进⼊。这种实现计数器限流⽅式由于是在⼀个时间间隔内进⾏限制,如果⽤户在上个时间间隔结束前请求(但没有超过限制),同时在当前时间间隔刚开始请求(同样没超过限制),在各⾃的时间间隔内,这些请求都是正常的,但是将间隔临界的⼀段时间内的请求就会超过系统限制,可能导致系统被压垮。
由于计数器算法存在时间临界点缺陷,因此在时间临界点左右的极短时间段内容易遭到攻击。⽐如设定每分钟最多可以请求100次某个接⼝,如12:00:00-12:00:59时间段内没有数据请求,⽽12:00:59-12:01:00时间段内突然并发100次请求,⽽紧接着跨⼊下⼀个计数周期,计数器清零,在12:01:00-12:01:01内⼜有100次请求。那么也就是说在时间临界点左右可能同时有2倍的阀值进⾏请求,从⽽造成后台处理请求过载的情况,导致系统运营能⼒不⾜,甚⾄导致系统崩溃。
缺点:
例如:限流是每秒3个,在第一秒的最后一毫秒发送了3个请求,在第二秒的第一毫秒又发送了3个请求。在这两毫米内处理了6个请求,但是并没有触发限流。如果出现突发流量,可能会压垮服务器。
滑动窗⼝算法是把固定时间⽚进⾏划分,并且随着时间移动,移动⽅式为开始时间点变为时间列表中的第⼆时间点,结束时间点增加⼀个时间点,不断重复,通过这种⽅式可以巧妙的避开计数器的临界点的问题。
滑动窗⼝算法可以有效的规避计数器算法中时间临界点的问题,但是仍然存在时间⽚段的概念。同时滑动窗⼝算法计数运算也相对固定时间窗⼝算法⽐较耗时。
缺点: 还是存在限流不够平滑的问题。例如:限流是每秒3个,在第一毫秒发送了3个请求,达到限流,剩余窗口时间的请求都将会被拒绝,体验不好。
总结
介绍了四种常用的限流算法:固定窗口算法、滑动窗口算法、漏桶算法和令牌桶算法。每种算法都有其特点和适用场景,下面我们来对它们进行简单的总结和比较。
令牌桶算法既能平滑流量,又能处理突发流量,适用于需要处理突发流量的场景。
漏桶算法的优点是流量处理更平滑,但是无法应对突发流量,适用于需要平滑流量的场景。
固定窗口算法 实现简单,但是限流不够平滑,存在窗口边界问题,适用于需要简单实现限流的场景。
滑动窗口算法解决了窗口边界问题,但是还是存在限流不够平滑的问题,适用于需要控制平均请求速率的场景。