熔断限流

  • 作者: 凯哥Java
  • Dubbo
  • 时间:2021-08-20 09:49
  • 153人已阅读
简介 限流根据排队理论,具有延迟的服务随着请求量的不断提升,其平均响应时间也会迅速提升,为了保证服务的SLA(Service-LevelAgreement服务等级协议),有必要控制单位时间的请求量。这就是限流为什么愈发重要的原因。分类qps限流限制每秒处理请求数不超过阈值并发限流限制同时处理的请求数目。Java中的Semaphore(信号量)是做并发限制的好工具,特别适用于资源有效的场景。单机限流Gua

限流

  • 根据排队理论,具有延迟的服务随着请求量的不断提升,其平均响应时间也会迅速提升,为了保证服务的SLA(Service-Level Agreement 服务等级协议),有必要控制单位时间的请求量。这就是限流为什么愈发重要的原因。

分类

  • qps限流

  • 限制每秒处理请求数不超过阈值

  • 并发限流

  • 限制同时处理的请求数目。Java 中的 Semaphore(信号量) 是做并发限制的好工具,特别适用于资源有效的场景。

单机限流

  • Guava 中的 RateLimiter(内部采用令牌捅算法实现)。

  • 集群限流

  • redis限流,计时器和计数器处理、key加秒为key

  • nginx(+lua)前端限流,按照一定的规则如帐号、IP、系统调用逻辑等在Nginx层面做限流

  • 算法

  • 常见的限流算法有:令牌桶、漏桶。计数器也可以进行粗暴限流实现。

  • 漏桶算法

  • 5c219c5b95f370e6e23c9205ed26688a.png

  • 令牌桶算法

  • 60f81dbf6829f4227db8cf1a3402d65e.png

实施方案

RPC限流(dubbo)

dubbo调用模型

连接调用图

d4e34e25709186355e98366bdbf9f3d4.png

调用时关键参数影响

6d73aaf55c4cfed812ba6e6d63fb94e1.png

分析

1:当consumer发起一个请求时,首先经过active limit(参数actives)进行方法级别的限制,其实现方式为CHM中存放计数器(AtomicInteger),请求时加1,请求完成(包括常)减1,如果超过actives则等待有其他请求完成后重试或者超时后失败;

2:从多个连接(connections)中选择一个连接发送数据,对于默认的netty实现来说,由于可以复用连接,默认一个连接就可以。不过如果你在压测,且只有一个consumer,一个provider,此时适当的加大connections确实能够增强网络传输能力。但线上业务由于有多个consumer多个provider,因此不建议增加connections参数;

3:连接到达provider时(如dubbo的初次连接),首先会判断总连接数是否超限(acceps),超过限制连接将被拒绝;

4:连接成功后,具体的请求交给io thread处理。io threads虽然是处理数据的读写,但io部分为异步,更多的消耗的是cpu,因此iothreads默认cpu个数+1是比较合理的设置,不建议调整此参数;

5:数据读取并反序列化以后,交给业务线程池处理,默认情况下线程池为fixed,且排队队列为0(queues),这种情况下,最大并发等于业务线程池大小(threads),如果希望有请求的堆积能力,可以调整queues参数。如果希望快速失败由其他节点处理(官方推荐方式),则不修改queues,只调整threads;

6:execute limit(参数executes)是方法级别的并发限制,原理与actives类似,只是少了等待的过程,即受限后立即失败;

7:tps,控制指定时间内(默认60s)的请求数。注意目前dubbo默认没有支持该参数

从上面的分析,可以看出如果 (consumer数 * actives > provider数 * threads) 且 (queues=0),则会存在部分请求无法申请到资源,重试也有很大几率失败。

当需要对一个接口的不同方法进行不同的并发控制时使用executes,否则调整threads就可以。

内容引用自 dubbo参数调优说明

dubbo filter

dubbo提供了多个和请求相关的filter 我们可以看到:ActiveLimitFilter ExecuteLimitFilter TPSLimiterFilter

ActiveLimitFilter

  • @Activate(group = Constants.CONSUMER, value = Constants.ACTIVES_KEY)

作用于客户端,控制客户端同样的方法可同时运行的次数【即该方法的并发度】

dubbo:reference   
配置类:org.apache.dubbo.config.ReferenceConfig
actives:(int default 0) 每服务消费者每服务每方法最大并发调用数  2.0.5以上版本


dubbo:consumer
配置类: org.apache.dubbo.config.ConsumerConfig   
同时为 dubbo:reference 缺省值设置  
default.actives:(int default 0) 每服务消费者每服务每方法最大并发调用数 2.0.5以上版本


dubbo:provider
配置类: org.apache.dubbo.config.ProviderConfig
同时为 dubbo:service 和 dubbo:protocol 缺省值设置
default.actives:(int default 0) 每服务消费者每服务每方法最大并发调用数 2.0.5以上版本

actives:消费者端的最大并发调用限制,即当 Consumer 对一个服务的并发调用到上限后,新调用会阻塞直到超时,在方法上配置 dubbo:method 则针对该方法进行并发限制,在接口上配置 dubbo:service,则针对该服务进行并发限制

建议在 Provider 端配置的 Consumer 端属性

当超过了指定的active值之后该请求将等待前面的请求完成

何时结束呢?依赖于该方法的timeout 如果没有设置timeout的话 可能就是多个请求一直被阻塞然后等待随机唤醒吧

搭配timeout一起使用


ExecuteLimitFilter


  • @Activate(group = Constants.PROVIDER, value = Constants.EXECUTES_KEY)

服务端限制

```
dubbo:service  
配置类:org.apache.dubbo.config.ServiceConfig  
executes:(int default 0) 服务提供者每服务每方法最大可并行执行请求数 2.0.5以上版
```
```
dubbo:provider  
配置类: org.apache.dubbo.config.ProviderConfig  
同时为 dubbo:service 和 dubbo:protocol 缺省值设置  
default.actives:(int default 0) 服务提供者每服务每方法最大可并行执行请求数 2.0.5以上版
```

一旦超出指定的数目直接报错 其实是指在服务端的并行度【需要注意这些都是指的是在单台服务上而不是整个服务集群】

TpsLimitFilter

  • @Activate(group = Constants.PROVIDER, value = Constants.TPS_LIMIT_RATE_KEY)

同样作用在服务端 目的在于控制一段时间类中的请求数。dubbo没有默认支持。

```
使用TpsLimitFilter  
Dubbo框架并没有默认通过配置文件启动这个Filter,  
所以我们需要在classpath的META-INF/dubbo/目录下增加com.alibaba.dubbo.rpc.Filter文件  
tps=com.alibaba.dubbo.rpc.filter.TpsLimitFilter
就算加上了这个配置,其实也还是生效不了,我们的provider url需要有tps=xxx参数  

相关操作比较繁琐,dubbo没有提供默认实现自有其不推荐使用的理由
```

Dubbo之限流TpsLimitFilter源码分析–简书

dubbo Sentinel

Sentinel 限流、熔断、降级

Sentinel 开源地址:https://github.com/alibaba/Sentinel

Sentinel以流量为切入点,从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性

Spring Cloud Alibaba

Sentinel 为 Dubbo 服务保驾护航

Sentinel



dubbo Hystrix

Hystrix 主要用于熔断降级


讨论

dubbo 全局限流实现方案及是否有必要?

API限流(http)

Nginx

对于Nginx接入层限流可以使用Nginx自带了两个模块:

连接数限流模块ngx_http_limit_conn_module和漏桶算法实现的请求限流模块ngx_http_limit_req_module。


ngx_http_limit_conn_module

我们经常会遇到这种情况,服务器流量异常,负载过大等等。对于大流量恶意的攻击访问,会带来带宽的浪费,服务器压力,影响业务,往往考虑对同一个ip的连接数,并发数进行限制。ngx_http_limit_conn_module 模块来实现该需求。该模块可以根据定义的键来限制每个键值的连接数,如同一个IP来源的连接数。并不是所有的连接都会被该模块计数,只有那些正在被处理的请求(这些请求的头信息已被完全读入)所在的连接才会被计数。

我们可以在nginx_conf的http{}中加上如下配置实现限制:


#限制每个用户的并发连接数,取名one 

limit_conn_zone $binary_remote_addr zone=one:10m;

配置记录被限流后的日志级别,默认error级别

limit_conn_log_level error;

#配置被限流后返回的状态码,默认返回503

limit_conn_status 503;

1

2

3

4

5

6

然后在server{}里加上如下代码:


#限制用户并发连接数为1

limit_conn one 1;

1

2

然后我们是使用ab测试来模拟并发请求:

ab -n 5 -c 5 http://10.23.22.239/index.html

得到下面的结果,很明显并发被限制住了,超过阈值的都显示503


另外刚才是配置针对单个IP的并发限制,还是可以针对域名进行并发限制,配置和客户端IP类似。


#http{}段配置

limit_conn_zone $ server_name zone=perserver:10m;

#server{}段配置

limit_conn perserver 1;

1

2

3

4

ngx_http_limit_req_module

上面我们使用到了ngx_http_limit_conn_module 模块,来限制连接数。那么请求数的限制该怎么做呢?这就需要通过ngx_http_limit_req_module 模块来实现,该模块可以通过定义的键值来限制请求处理的频率。特别的,可以限制来自单个IP地址的请求处理频率。 限制的方法是使用了漏斗算法,每秒固定处理请求数,推迟过多请求。如果请求的频率超过了限制域配置的值,请求处理会被延迟或被丢弃,所以所有的请求都是以定义的频率被处理的。

在http{}中配置


#区域名称为one,大小为10m,平均处理的请求频率不能超过每秒一次。

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;

1

2

在server{}中配置


#设置每个IP桶的数量为5

limit_req zone=one burst=5;

1

2

上面设置定义了每个IP的请求处理只能限制在每秒1个。并且服务端可以为每个IP缓存5个请求,如果操作了5个请求,请求就会被丢弃。

使用ab测试模拟客户端连续访问10次:ab -n 10 -c 10 http://10.23.22.239/index.html

设置了桶的个数为5个。一共10个请求,第一个请求马上被处理。第2-6个被存放在桶中。由于桶满了,没有设置nodelay因此,余下的4个请求被丢弃。


openresty(nginx+lua)

OpenResty实现限流的几种方式


spring cloud的zuul

Spring Cloud:服务网关 Zuul


Zuul 是开源的微服务网关,可与 Eureka、Ribbon、Hystrix 等组件配合使用,Zuul 它的核心是一系列过滤器,这些过滤器可完成下面功能:

身份认证与安全:识别每个资源的验证要求,并拒绝那些要求不符合的请求

审核与监控:在边缘位置追踪有意义的数据和统计结果,从而带来精确的生产视图

动态路由:动态的将请求路由到不同的后端集群

压力测试:逐渐增加指向集群的流量,以了解性能

负载分配:为每一种负载类型分配对应容量,并弃用超出限定值的请求

静态响应处理:在边缘位置直接建立部分响应,从而避免转发到内部集群

多区域弹性:跨越 AWS Region 进行请求路由,实现 ELB 使用多样化,让系统边缘更贴近使用者

Spring Cloud 对 Zuul 进行了整合和增强,Zuul 默认使用的 HTTP 客户端是 Apache Http Client,也可使用 RestClient 或 okHttpClient

内容引用 Spring Cloud:服务网关 Zuul


spring cloud Hystrix

Hystrix 主要用于熔断降级


Hystrix的设计原则

防止单个服务的故障耗尽整个服务的Servlet容器(如Tomcat)的线程池资源。

快速失败机制,如果某个服务出现了故障,则调用该服务的请求快速失败,而不是线程等待。

提供回退方案,在请求发生故障时,提供设定好的回退方案。

使用熔断器机制,防止故障扩散到其他的服务。

提供熔断器的监控组件Hystrix Dashboard,可以实时监控熔断器的状态。

Hystrix的工作机制

当服务的某个API接口的失败次数在一定时间内小于设定的阈值时,熔断器处于关闭状态,该API接口正常提供服务。

当该API接口处理请求的失败次数大于设定的阈值时,Hystrix判定该API接口出现了故障,打开熔断器,这时该API接口会执行快速失败的逻辑,不执行业务逻辑,请求的线程不会处于阻塞状态。

处于打开状态的熔断器在一定时间后会处于半打开状态,并将一定数量的请求执行正常逻辑,剩余的请求会执行快速失败。

若执行正常逻辑的请求失败了,则熔断器继续打开,若成功了,则熔断器关闭。这样熔断器就具有了自我修复的功能。

内容引用 熔断器Hystrix




————————————————

版权声明:本文为CSDN博主「zhaokuner」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。

原文链接:https://blog.csdn.net/zhaokuner/article/details/103355996

Top Top