--- highlight: a11y-dark --- 携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第14天，[点击查看详情](https://juejin.cn/post/7123120819437322247) # 前言在高并发的系统中，往往需要在系统中做限流，一方面是为了防止大量的请求使服务器过载，导致服务不可用，另一方面是为了防止网络攻击。常见的限流方式，比如Hystrix适用线程池隔离，超过线程池的负载，走熔断的逻辑。在一般应用服务器中，比如tomcat容器也是通过限制它的线程数来控制并发的；也有通过时间窗口的平均速度来控制流量。常见的限流纬度有比如通过Ip来限流、通过uri来限流、通过用户访问频次来限流。一般限流都是在网关这一层做，比如Nginx、Openresty、kong、zuul、Spring Cloud Gateway等；也可以在应用层通过Aop这种方式去做限流。限流的目的是通过对并发访问／请求进行限速或者对一个时间窗口内的请求进行限速来保护系统，一旦达到限制速率则可以拒绝服务（定向到错误页或友好的展示页）、排队或等待（比如秒杀、评论、下单等场景）、降级（返回兜底数据或默认数据）。一般的中间件都会有单机限流框架，支持两种限流模式：控制速率和控制并发。 # 常见的限流算法 ## 计数器算法计数器算法采用计数器实现限流有点简单粗暴，一般我们会限制一秒钟的能够通过的请求数，比如限流qps为100，算法的实现思路就是从第一个请求进来开始计时，在接下去的1s内，每来一个请求，就把计数加1，如果累加的数字达到了100，那么后续的请求就会被全部拒绝。等到1s结束后，把计数恢复成0，重新开始计数。具体的实现可以是这样的：对于每次服务调用，可以通过AtomicLong#incrementAndGet()方法来给计数器加1并返回最新值，通过这个最新值和阈值进行比较。这种实现方式，相信大家都知道有一个弊端：如果我在单位时间1s内的前10ms，已经通过了100个请求，那后面的990ms，只能眼巴巴的把请求拒绝，我们把这种现象称为“突刺现象” ## 漏桶算法漏桶算法为了消除”突刺现象”，可以采用漏桶算法实现限流，漏桶算法这个名字就很形象，算法内部有一个容器，类似生活用到的漏斗，当请求进来时，相当于水倒入漏斗，然后从下端小口慢慢匀速的流出。不管上面流量多大，下面流出的速度始终保持不变。不管服务调用方多么不稳定，通过漏桶算法进行限流，每10毫秒处理一次请求。因为处理的速度是固定的，请求进来的速度是未知的，可能突然进来很多请求，没来得及处理的请求就先放在桶里，既然是个桶，肯定是有容量上限，如果桶满了，那么新进来的请求就丢弃。 ![在这里插入图片描述](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a0d75674bb72407da26e6779d4f979ea~tplv-k3u1fbpfcp-zoom-1.image)在算法实现方面，可以准备一个队列，用来保存请求，另外通过一个线程池（ScheduledExecutorService）来定期从队列中获取请求并执行，可以一次性获取多个并发执行。这种算法，在使用过后也存在弊端：无法应对短时间的突发流量。 ## 令牌桶算法从某种意义上讲，令牌桶算法是对漏桶算法的一种改进，桶算法能够限制请求调用的速率，而令牌桶算法能够在限制调用的平均速率的同时还允许一定程度的突发调用。在令牌桶算法中，存在一个桶，用来存放固定数量的令牌。算法中存在一种机制，以一定的速率往桶中放令牌。每次请求调用需要先获取令牌，只有拿到令牌，才有机会继续执行，否则选择选择等待可用的令牌、或者直接拒绝。放令牌这个动作是持续不断的进行，如果桶中令牌数达到上限，就丢弃令牌，所以就存在这种情况，桶中一直有大量的可用令牌，这时进来的请求就可以直接拿到令牌执行，比如设置qps为100，那么限流器初始化完成一秒后，桶中就已经有100个令牌了，这时服务还没完全启动好，等启动完成对外提供服务时，该限流器可以抵挡瞬时的100个请求。所以，只有桶中没有令牌时，请求才会进行等待，最后相当于以一定的速率执行。 ![在这里插入图片描述](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f0c05294a27d43fe932e470c2539f9a1~tplv-k3u1fbpfcp-zoom-1.image) 实现思路：可以准备一个队列，用来保存令牌，另外通过一个线程池定期生成令牌放到队列中，每来一个请求，就从队列中获取一个令牌，并继续执行。 ## RequestRateLimiterGatewayFilterFactory 限流作为网关最基本的功能，Spring Cloud Gateway官方就提供RequestRateLimiterGatewayFilterFactory这个类。 RequestRateLimiterGatewayFilter 工厂使用 RateLimiter 实现来确定是否允许继续处理当前请求。如果不是，则返回 HTTP 429 - Too Many Requests（默认情况下）状态。 RequestRateLimiterGatewayFilter采用可选的 keyResolver 参数和特定于速率限制器的参数 ### KeyResolver keyResolver 是一个实现 KeyResolver 接口的 bean。在配置中，使用 SpEL 按名称引用 bean。 #{@myKeyResolver} 是一个 SpEL 表达式，它引用名为 myKeyResolver 的 bean。 KeyResolver 的默认实现是 PrincipalNameKeyResolver，它从 ServerWebExchange 检索 Principal 并调用 Principal.getName()。默认情况下，如果 KeyResolver 没有找到key，请求将被拒绝。可以以下通过设置来调整此行为 spring.cloud.gateway.filter.request-rate-limiter.deny-empty-key (Boolean) 和spring.cloud.gateway.filter.request-rate-limiter.empty-key-status-code（String） ## RedisRateLimiter RequestRateLimiterGatewayFilterFactory使用redis和lua脚本来实现令牌桶算法，lua脚本在RequestRateLimiterGatewayFilterFactory所在的包META-INF/scripts中 ![在这里插入图片描述](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/563dea7c5e734f5eac24749ef4c59ea3~tplv-k3u1fbpfcp-zoom-1.image) 使用RedisRateLimiter需要引入spring-boot-starter-data-redis-reactive包，RedisRateLimiter使用的是令牌桶算法。 - redis-rate-limiter.replenishRate :希望允许用户每秒执行多少请求，而没有任何丢弃的请求。这是令牌桶填充的速率。 - redis-rate-limiter.burstCapacity :允许用户在一秒内执行的最大请求数。这是令牌桶可以容纳的令牌数量。将此值设置为零会阻止所有请求。 - redis-rate-limiter.requestedTokens : 请求需要使用多少令牌。这是每个请求从桶中取出的令牌数量，默认为1。通过在replenishRate 和burstCapacity 中设置相同的值来实现稳定的速率。通过将burstCapacity 设置为高于replenishRate ，可以允许临时突发。在这种情况下，需要允许速率限制器在突发之间有一段时间（根据replenishRate ），因为两个连续的突发将导致请求丢失（HTTP 429 - Too Many Requests）。 ## 实现这些实现的限流的项目都是在我之前的springcloud学习的基础上实现的，有兴趣的可以查看 [springcloud 入门(1) eureka注册中心](https://juejin.cn/post/7127527934880907272) [springcloud 入门(10) Spring Security 安全与权限](https://juejin.cn/post/7129691975103545357) [springcloud 入门之网关 springcloud gateway](https://juejin.cn/post/7129321738248126478) 1、在cloud-gateway springboot 项目中引入依赖 ```java org.springframework.cloud spring-cloud-starter-gateway org.springframework.boot spring-boot-starter-data-redis-reactive ``` 2、实现KeyResolver接口 ```java @Component public class UriKeyResolver implements KeyResolver { @Override public Mono resolve(ServerWebExchange exchange) { final String path = exchange.getRequest().getURI().getPath(); System.out.println(path); return Mono.just(path); } } ``` UriKeyResolver是对URI进行限流。 3、修改配置文件 ```java server.port=7201 spring.application.name=CLOUD-GATEWAY # 路由配置 spring.cloud.gateway.routes[0].id=my_csdn_route spring.cloud.gateway.routes[0].uri=http://blog.csdn.net/ spring.cloud.gateway.routes[0].predicates[0]=Path=/qq_39654841 # 限流过滤器 spring.cloud.gateway.routes[0].filters[0].name=RequestRateLimiter #令牌桶每秒填充平均速率 spring.cloud.gateway.routes[0].filters[0].args.redis-rate-limiter.replenishRate=1 #令牌桶总容量 spring.cloud.gateway.routes[0].filters[0].args.redis-rate-limiter.burstCapacity=10 #用于限流的键的解析器的 Bean 对象的名字。它使用 SpEL 表达式根据#{@beanName}从 Spring 容器中获取 Bean 对象 spring.cloud.gateway.routes[0].filters[0].args.key-resolver=#{@uriKeyResolver} # redis spring.redis.host=localhost spring.redis.port=6379 spring.redis.database=0 spring.redis.jedis.pool.max-active=8 ``` 4、测试访问http://localhost:7201/qq_39654841 ，使用postman迭代20次进行测试，可以发现会有 HTTP 429 - Too Many Requests报错 ![在这里插入图片描述](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/99a71311cbc14a55958f4b0e39fc821d~tplv-k3u1fbpfcp-zoom-1.image) 查看redis会有限流存储的key的信息，关于key的含义可以查看lua脚本 ![在这里插入图片描述](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d133a45d51524d048537ab4b82fb553c~tplv-k3u1fbpfcp-zoom-1.image) 至此，Spring Cloud Gateway 限流就到此结束了。学习更多关于springcloud的可以关注我的 [springcloud 专栏](https://juejin.cn/column/7073756305214668830) GitHub地址： https://github.com/ArronSun/micro-services-practice.git 参考： > 《重新定义springcloud 实战》 > https://docs.spring.io/spring-cloud-gateway/docs/current/reference/html/#the-requestratelimiter-gatewayfilter-factory > https://www.fangzhipeng.com/springcloud/2018/12/22/sc-f-gatway4.html 能力一般，水平有限，如有错误，请多指出。