限流

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

分类

• qps限流

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

• 并发限流

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

• 单机限流

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

• 集群限流

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

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

算法

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

• 漏桶算法
  

• 令牌桶算法
  

实施方案

RPC限流（dubbo）

dubbo调用模型

连接调用图

调用时关键参数影响

参数名	作用范围	默认值	说明	备注
actives	consumer	0	每服务消费者每服务每方法最大并发调用数	0表示不限制
connections	consumer		对每个提供者的最大连接数，rmi、http、hessian等短连接协议表示限制连接数，dubbo等长连接协表示建立的长连接个数	dubbo时为1，即复用单链接
accepts	provider	0	服务提供方最大可接受连接数	0表示不限制
iothreads	provider	cpu个数+1	io线程池大小(固定大小)
threads	provider	200	业务线程池大小(固定大小)
executes	provider	0	服务提供者每服务每方法最大可并行执行请求数	0表示不限制
tps	provider		指定时间内（默认60s）最大的可执行次数，注意与executes的区别	默认不开启
queues	provider	0	线程池队列大小，当线程池满时，排队等待执行的队列大小，建议不要设置，当线程程池时应立即失败，重试其它服务提供机器，而不是排队，除非有特殊需求。

分析

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;	
  

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

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

  然后我们是使用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;	
  

• 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;
  

  在server{}中配置

  #设置每个IP桶的数量为5
  limit_req zone=one burst=5;
  

  上面设置定义了每个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