RequestRateLimiter
RequestRateLimiter
GatewayFilter
工厂使用 RateLimiter
实现来确定是否允许当前请求继续进行。如果不允许,就会返回 HTTP 429 - Too Many Requests
(默认)的状态。
这个过滤器需要一个可选的 keyResolver
参数和特定于速率限制器的参数。
keyResolver
是一个实现了 KeyResolver
接口的Bean。在配置中,使用SpEL来引用Bean的名字。#{@myKeyResolver}
是一个SpEL表达式,它引用了一个名为 myKeyResolver
的bean。下面的列表显示了 KeyResolver
的接口。
Example 42. KeyResolver.java
public interface KeyResolver {
Mono<String> resolve(ServerWebExchange exchange);
}
KeyResolver
接口让可插拔的策略导出限制请求的key。在未来的里程碑版本中,会有一些 KeyResolver
的实现。
KeyResolver
的默认实现是 PrincipalNameKeyResolver
,它从 ServerWebExchange
中检索 Principal
并调用 Principal.getName()
。
默认情况下,如果 KeyResolver
没有找到一个 key
,请求会被拒绝。你可以通过设置 spring.cloud.gateway.filter.request-rate-limiter.deny-empty-key
(true
或 false
)和 spring.cloud.gateway.filter.request-rate-limiter.empty-key-status-code
属性来调整这种行为。
RequestRateLimiter
不能用 "快捷方式" 来配置。下面的例子是无效的。Example 43. application.properties
# 无效的快捷方式配置 spring.cloud.gateway.routes[0].filters[0]=RequestRateLimiter=2, 2, #{@userkeyresolver}
Redis RateLimiter
Redis的实现是基于 Stripe 的工作。它需要使用 spring-boot-starter-data-redis-reactive Spring Boot Starter。 使用的算法是 令牌桶算法。
常用的更平滑的限流算法有两种:漏桶算法 和 令牌桶算法。
漏桶算法
漏桶算法思路很简单,水(请求)先进入到漏桶里,漏桶以一定的速度出水(接口有响应速率),当水流入速度过大会直接溢出(访问频率超过接口响应速率),然后就拒绝请求,可以看出漏桶算法能强行限制数据的传输速率。
可见这里有两个变量,一个是桶的大小,支持流量突发增多时可以存多少的水(burst),另一个是水桶漏洞的大小(rate)。因为漏桶的漏出速率是固定的参数,所以,即使网络中不存在资源冲突(没有发生拥塞),漏桶算法也不能使流突发(burst)到端口速率。因此,漏桶算法对于存在突发特性的流量来说缺乏效率。
令牌桶算法
令牌桶算法 和漏桶算法 效果一样但方向相反的算法,更加容易理解。随着时间流逝,系统会按恒定 1/QPS 时间间隔(如果 QPS=100,则间隔是 10ms)往桶里加入 Token(想象和漏洞漏水相反,有个水龙头在不断的加水),如果桶已经满了就不再加了。新请求来临时,会各自拿走一个 Token,如果没有 Token 可拿了就阻塞或者拒绝服务。
令牌桶的另外一个好处是可以方便的改变速度。一旦需要提高速率,则按需提高放入桶中的令牌的速率。一般会定时(比如 100 毫秒)往桶中增加一定数量的令牌,有些变种算法则实时的计算应该增加的令牌的数量。
redis-rate-limiter.replenishRate
属性定义了每秒钟允许多少个请求(不算放弃的请求)。这是令牌桶被填充的速度。
redis-rate-limiter.burstCapacity
属性是一个用户在一秒钟内允许的最大请求数(不算放弃的请求)。这是令牌桶可以容纳的令牌数量。将此值设置为零会阻止所有请求。
redis-rate-limiter.requestedTokens
属性是指一个请求要花费多少令牌。这是为每个请求从桶中提取的令牌数量,默认为 1
。
一个稳定的速率是通过在 replenishRate
和 burstCapacity
中设置相同的值来实现的。可以通过设置高于补给率的 burstCapacity
来允许临时的突发。在这种情况下,速率限制器需要在突发之间允许一些时间(根据 replenishRate
),因为连续两次突发会导致请求被放弃(HTTP 429 - Too Many Requests
)。下面的列表配置了一个 redis-rate-limiter
。
低于 1个请求/s 的速率限制是通过将 replenishRate
设置为想要的请求数, requestTokens
设置为秒数,burstCapacity
设置为 replenishRate
和 requestTokens
的乘积来完成的。例如,设置 replenishRate=1
,requestedTokens=60
,burstCapacity=60
,结果是1个请求/分钟的限制。
Example 44. application.yml
spring:
cloud:
gateway:
routes:
- id: requestratelimiter_route
uri: https://example.org
filters:
- name: RequestRateLimiter
args:
redis-rate-limiter.replenishRate: 10
redis-rate-limiter.burstCapacity: 20
redis-rate-limiter.requestedTokens: 1
下面的例子在Java中配置了一个 KeyResolver
。
Example 45. Config.java
@Bean
KeyResolver userKeyResolver() {
return exchange -> Mono.just(exchange.getRequest().getQueryParams().getFirst("user"));
}
这定义了每个用户的请求率限制为10。爆发20次是允许的,但是,在下一秒,只有10个请求可用。KeyResolver
是一个简单的,获得 user
请求参数。
你也可以把速率限制器定义为一个实现 RateLimiter
接口的bean。在配置中,你可以用SpEL来引用bean的名字。#{@myRateLimiter}
是一个SpEL表达式,它引用了一个名为 myRateLimiter
的 bean。下面的清单定义了一个速率限制器,它使用了前面清单中定义的 KeyResolver
。文章来源:https://www.toymoban.com/news/detail-588805.html
Example 46. application.yml文章来源地址https://www.toymoban.com/news/detail-588805.html
spring:
cloud:
gateway:
routes:
- id: requestratelimiter_route
uri: https://example.org
filters:
- name: RequestRateLimiter
args:
rate-limiter: "#{@myRateLimiter}"
key-resolver: "#{@userKeyResolver}"
到了这里,关于Spring Cloud—GateWay之限流的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!