一、前言
随着微服务的流行,服务和服务之间的依赖越来越强,调用关系越来越复杂,服务和服务之间的稳定性越来越重要。在遇到突发的请求量激增,恶意的用户访问,亦或请求频率过高给下游服务带来较大压力时,我们常常需要通过缓存、限流、熔断降级、负载均衡等多种方式保证服务的稳定性。
二、限流的场景及目的
限流的场景无处不在,有感知的,或许也有一些无感知的,简要介绍下如下一些场景
限流的业务场景主要有以下几点
- 对自己的服务进行流量控制,防止恶意请求流量、恶意攻击,或者防止流量超出系统峰值导致系统瘫痪
- 对底层服务的保护,如:A系统调用B系统,B系统自身没有任何防护措施且处理业务的能力有很大的瓶颈,如果大量请求直接落到了B服务,则会导致自身服务甚至波及到其他与B服务有交互的业务瘫痪
- 对数据源的保护,如:A数据库读写QPS能力有限,调用防如没有有效的控制交互的频率,数据库挂则业务挂,缓存也就可以起到降低对底层数据源访问的频率
- 保证服务全链路7 * 24小时稳定运行,如:A系统调用B系统,B系统有防护措施,如因为流量突然的增大,B系统因为对自身服务的保护而把A系统拉入黑名单,此时就无法保证服务的7*24小时稳定运行
三、限流的时机
以图形的形式,描述一个全场景,来表述限流的时机

如上图1,2,3,4,5,6是不是都可以进行限流
1、nginx网关统一进行流量限流
2、tomcat服务通过控制连接资源,最大线程数,最小线程数,阻塞队列等配置来通过资源限制起到限流效果
3、数据库连接池限流方式同2
4、http连接池限流方式同2
5、kafka生产者限流方式同2
6、kafka服务器通过topic,分区key,队列等配置,限制消费的速度来起到限流效果
通过上述案例,总结出限流的时机处于(接收或发出)的(异步或同步)请求
四、如何实现限流

限流就是在某个时间窗口对资源访问做限制,比如设定每秒最多100个访问请求。但在真正的场景里,我们不止设置一种限流规则,而是会设置多个限流规则共同作用,主要的几种限流规则如下:
- QPS和连接数控制
- 可设定IP维度的限流,也可以设置基于单个服务器的限流
- 传输速率
- 资源的下载速度
- 黑白名单
- 分布式环境
- 网关层限流
常见的算法有如下四种
- 计数器限流算法
- 滑动窗口限流算法
- 令牌桶限流算法
- 漏桶限流算法
1. 计数器限流算法
在有效时间内计算请求次数,调用一次+1,调用结束-1,可以使用redis的incr或其他计数工具实现。

- 优点:实现简单
- 缺点:第一个时间段的结尾和第二个时间段的开头组成的新时间段容易超过阈值。例如:5秒内请求不能超过10次,第一个5秒是0-5,第二个是5-10,那你在4.9秒、5.1秒时分别请求10次,但其实4.9和5.1之间不过0.2秒而已,但却请求了20次,会超过10次的阈值。
- 适用场景:短信验证码,间隔固定时间可重复发送
2. 滑动窗口限流算法
其实也是一种计数器限流算法,只不过每过一个步长,整体时间区域滑动一下,以滑动窗口的机制减少临界值带来的超过阈值的问题。

-
优点:有效降低了临界值带来的超过阈值的问题
-
缺点:计数器的问题没有从根本上得到解决,只是范围缩小了。例如:还是5秒内请求不能超过10次,滑动窗口步长为1秒,那么在初始是0-5秒,第一次滑动是1-6秒。在滑动前的0.9秒和滑动后的5.1秒分别请求10次,在0.9和5.1之间不到5秒,请求了20次,又超过了10次的阈值。
-
第三方实现:Spring的熔断(Hystrix)
3. 令牌桶限流算法
有一个令牌桶和定时器,在一个时间段内往令牌桶里生成固定数量的令牌,你请求就从桶里拿一个令牌,如果令牌没了,就排队或拒绝服务。

-
优点:解决了计数器限流算法的临界值超过阈值的问题。并且可以支持突发的流程,把令牌一下子全部拿走。
-
缺点:不能保持匀速请求的处理
-
适用场景:突峰流量、瞬时流量
第三方实现:Google的Guava,Redisson限流
4. 漏桶限流算法
恒定速率的限流算法,不论客户端请求量是多少,服务端处理请求的速度都是恒定的。请求过来,先放到一个队列里,然后服务端以一定的频率去漏桶处理请求。若漏桶队列满了,则请求排队或拒绝服务。

- 优点:可以实现请求处理速度的恒定缺点:
- 对突峰、瞬时流量处理速度过慢
- 适用场景:基于MQ实现的生产者消费者模型
文章介绍了在微服务环境中,服务稳定性的重要性以及限流作为保障手段的必要性。限流适用于防止恶意请求、保护底层服务和数据源,以及确保全链路的稳定运行。限流可以在不同层次如Nginx、应用服务器、数据库连接池等实施。文章列举了四种限流算法:计数器、滑动窗口、令牌桶和漏桶,分析其优缺点和适用场景。
1100

被折叠的 条评论
为什么被折叠?



