艾编教学笔记：高并发限流+分布式限流高并发限流技术揭秘

内容概要：

1、为什么要限流

2、分布式限流解决方案

3、Guava实现令牌限流和漏桶限流

4、SpringBoot结合Redis实现分布式限流

5、SpringCloud GateWay网关限流---微服务SprignCloud 6、Nginx限流

为什么要限流

目标

学习在项目开发中为什么要使用限流技术，以及限流的作用。

概述

在分布式领域，我们难免会遇到并发量突增，对后端服务造成高压力，严重甚至会导致系统宕机。为避免这种问题，我们通常会为接口添加限流、降级、熔断等能力，从而使接口更为健壮。Java领域常见的开源组件有Net?ix的hystrix，阿里系开源的sentinel等，都是蛮不错的限流熔断框架。

图解

在开发高并发系统时有三把利器用来保护系统：缓存、降级和限流。缓存的目的是提升系统访问速度和增大系统能处理的容量，可谓是抗高并发流量的银弹；而降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉，待高峰或者问题解决后再打开；而有些场景并不能用缓存和降级来解决，比如稀缺资源（秒杀、抢购）、写服务（如评论、下单）、频繁的复杂查询（评论的最后几页），因此需有一种手段来限制这些场景的并发/请求量，即限流。

解决一个问题：保护、保证系统一定可用。

解决方案

扩容

增加物理服务的硬件和设备。

缓存

缓存比较好理解，在大型高并发系统中，如果没有缓存数据库将分分钟被爆，系统也会瞬间瘫痪。使用缓存不单单能够提升系统访问速度、提高并发访问量，也是保护数据库、保护系统的有效方式。大型网站一般主要是“读”，缓存的使用很容易被想到。在大型“写”系统中，缓存也常常扮演者非常重要的角

色。比如累积一些数据批量写入，内存里面的缓存队列（生产消费），以及HBase写数据的机制等等也都是通过缓存提升系统的吞吐量或者实现系统的保护措施。甚至消息中间件，你也可以认为是一种分布式的数据缓存。

降级

服务降级是当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。降级往往会指定不同的级别，面临不同的异常等级执行不同的处理。根据服务方式：可以拒接服务，可以延迟服务，也有时候可以随机服务。根据服务范围：可以砍掉某个功能，也可以砍掉某些模块。总之服务降级需要根据不同的业务需求采用不同的降级策略。主要的目的就是服务虽然有损但是总比没有好。

限流

限流可以认为服务降级的一种，限流就是限制系统的输入和输出流量已达到保护系统的目的。一般来说系统的吞吐量是可以被测算的，为了保证系统的稳定运行，一旦达到的需要限制的阈值，就需要限制流量并采取一些措施以完成限制流量的目的。比如：延迟处理，拒绝处理，或者部分拒绝处理等等。

限流的目的

限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统，一旦达到限制速率则可以拒绝服务（定向到错误页或告知资源没有了）、排队或等待（比如秒杀、评论、下单）、降级（返回兜底数据或默认数据，如商品详情页库存默认有货）。

一般开发高并发系统常见的限流有：限制总并发数（比如数据库连接池、线程池）、限制瞬时并发数

（如nginx的limit_conn模块，用来限制瞬时并发连接数）、限制时间窗口内的平均速率（如Guava的RateLimiter、nginx的limit_req模块，限制每秒的平均速率）；其他还有如限制远程接口调用速率、限制MQ的消费速率。另外还可以根据网络连接数、网络流量、CPU或内存负载等来限流。

先有缓存这个银弹，后有限流来应对618、双十一高并发流量，在处理高并发问题上可以说是如虎添翼，不用担心瞬间流量导致系统挂掉或雪崩，最终做到有损服务而不是不服务；限流需要评估好，不可乱用，否则会正常流量出现一些奇怪的问题而导致用户抱怨。

保护、保证系统和网站的正常运行。

使用场景

秒杀、抢购，年底查询密集，评论查询。

SpringBoot结合Redis实现分布式限流演进

目标

为什么使用分布式限流解决方案，整个过程是如何来的。

步骤

1：搭建springboot框架

2：导入web依赖，和guava依赖，以及redis依赖


org.springframework.boot
spring-boot-starter-data-redis


org.springframework.boot

spring-boot-starter-web


org.springframework.boot
spring-boot-starter-test
test

3：最简单的限流讲解---计数器限流

package com.itheima.limiting.web;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class OrderController {
// 抢购，抢购数量，也就限流的阈值
static long limit = 10;
// 计算器，代表请求的用户数量
private long count = 0;
@GetMapping("/makeorder")
public String makeOrder(){
long c = ++count;
if(c > limit){
return "抢购结束，下次在来! count = " + c;
}
return "恭喜，抢购成功，count = " + c;
}
}

存在问题：

1：当前count没有标记成为static。需要标记成static吗？答案是不需要，因为 @RestController 标记当前类是单例的, 所以在内存中count只有一份，不会出现所谓的多份问题。而是共用的一个计数器。

2：往往在分布式集群的项目中，项目是部署多多台，是多个 jvm。每个jvm都又自己的计数器，这个时候就会引发高并发带来的线程安全问题。

3：那可以使用volatile 吗？答案是不可以。因为volatile只保证成员变量在线程见的可见性，它不保证线程安全。

4：如果线程不安全可以使用synchronized ，这种是没问题的，可以解决线程安全的问题。但是同时带

@GetMapping("/makeorder")
public synchronized String makeOrder(){
long c = ++count;
if(c > limit){
return "抢购结束，下次在来! count = " + c; 6    }
        return    "恭喜，抢购成功，count = " + c; 8    }

来的隐患就是：性能低下，这个是必然的，如果使用了synchronized关键字，就是上了锁，代码的执行就编程了串行，一大推的阻塞，如果这个时候又1w的并发，这个时候处理都会造成大量的阻塞。而且性能极低。在一般的开发中我们都会认为和代码是不适合的。也满足不了我们高并发的需要。那么进行优化，如何解决呢？原子类。

5：如果在分布式环境下呢？

可以使用分布式缓存来解决这个问题：

为什么不用Lock和synchronized，在单机环境下，是没有问题，但是往往在开发中，大部分情况下是集群环境，这个适合每个电脑都是独立JVM环境，你是没有办法去控制别人jvm内存中的东西，所以我们要计数器进行共享。

为什么选择Redis呢？而不是memcache操作呢？

答案很简单：Redis单线程。（基于linux的io模型来架构的，EPOLL 异步IO BIO NIO EPOLL ） jedis redission

代码如下：

引入依赖：


redis.clients
jedis
3.1.0

@GetMapping("makeorder2")
public String makeOrder2(String name){
// 从jedis上获取自增值
try(Jedis jedis = new Jedis("localhost",6379)){
long c = jedis.incr(name);
if(c > limit){
return "抢购结束，下次在来! count = " + c; 8    }
        return    "恭喜，抢购成功，count = " + c; 10    }
11    }

测试：启动8080和8081两个端口：访问

http://localhost:8081/makeorder2?name=lisi 和 http://localhost:8080/makeorder2?name=lisi 模拟同一个用户在集群环境下的并发问是否共享计数器。答案很明显是可以的。

限流接口的时间窗请求数--时间窗限流

概述

即一个时间窗口内的请求数，如需限制某个接口/服务每秒/每分钟/每天的请求数/调用量。

如果实现呢？

Guava---单机系统

使用LoadingCache限流

package com.itheima.limiting.web;
import com.google.common.cache.CacheBuilder;
import com.google.common.cache.CacheLoader;
import com.google.common.cache.LoadingCache;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import redis.clients.jedis.Jedis;
import java.util.Calendar;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicLong;
@RestController
public class OrderGuavaController {
// 抢购，抢购数量，也就限流的阈值
static long limit = 5;
// 限时间窗请求数，限制5r/s
LoadingCache loadingCache =
CacheBuilder.newBuilder().expireAfterAccess(2, TimeUnit.SECONDS)
.build(new CacheLoader() {
@Override
public AtomicLong load(Long aLong) throws Exception {
return new AtomicLong(0);
}
});
@GetMapping("/makeorder3")
public String makeOrder() throws Exception{
// 当前秒
long currentTime = System.currentTimeMillis()/1000L;
//long c = atomicLong.incrementAndGet();
long c = loadingCache.get(currentTime).incrementAndGet();
if(c > limit){
return "抢购结束，下次在来! count = " + c;
}
return "恭喜，抢购成功，count = " + c;
}
}

模拟代码：

package com.itheima.limiting.limiter;
import java.util.HashMap;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.ConcurrentMap;
import java.util.concurrent.atomic.AtomicLong;
public class MyLimiter {
private ConcurrentMap map = new ConcurrentHashMap<>
();
private long before;
public MyLimiter(long before){
super();
this.before = before;
}
public AtomicLong get(long key){
if(!this.map.containsKey(key)){
synchronized (map){
if(!this.map.containsKey(key)){
map.put(key,new AtomicLong(0L));
// 移除指定秒数的计数器
this.removeBeforeKey(key);
}
}
}
return this.map.get(key);
}
private void removeBeforeKey(long ckey){
for(Long key : this.map.keySet()){
// 把哪些超过时间的key，从map中移除出去。
if(key + before < ckey){
this.map.remove(key);
}
}
}
}

分布式限流--Lua脚本

目标使用lua脚本完成分布式限流步骤

package com.itheima.limiting.web;
import com.google.common.cache.CacheBuilder;
import com.google.common.cache.CacheLoader;
import com.google.common.cache.LoadingCache;
import com.itheima.limiting.limiter.MyLimiter;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import redis.clients.jedis.Jedis;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicLong;
@RestController
public class OrderRedisController {
// 抢购，抢购数量，也就限流的阈值
static long limit = 5;
public String makeorder6(String name) throws Exception{
try (Jedis jedis = new Jedis("localhost",6379)){
long c = jedis.incr(name);
if(c > limit){
return (System.currentTimeMillis()/1000)+"抢购结束，下次在来!
count = " + c;
}else{
if(c==1){
// 设置过期时间
jedis.expire(name,1);
}
}
return (System.currentTimeMillis()/1000) + "恭喜，抢购成功，count
= " + c;
}
}
}

Lua脚本

local key = KEYS[1] --限流Key(一秒一个)
local limit = tonumber(ARGV[1]) --限流大小
local expire = ARGV[2] --过期时间
-- 获取当前计数器的值
local current = tonumber(redis.call('get',key) or "0")
-- 如果超过限制大小
if current + 1 > limit then
return 0
Redis处理类
测试用例
else
current = tonumber(redis.call('INCRBY',key,"1")) --请求数+1
if current == 1 then --如果是第一次访问需要设置过期时间
redis.call("expire",key,expire) --设置过期时间
end
end
return 1 --返回1代表不限流

Redis处理类

package com.itheima.limiting.limiter;
import com.google.common.io.Files;
import org.springframework.core.io.ClassPathResource;
import redis.clients.jedis.Jedis;
import java.nio.charset.Charset;
public class JedisLuaLimiter {
private String luascript;
private String key;
private String limit;
private String expire;
public JedisLuaLimiter(String key,String limit,String expire,String
scriptFile){
super();
this.key = key;
this.limit = limit;
this.expire = expire;
try{
this.luascript = Files.asCharSource(new
ClassPathResource(scriptFile).getFile(), Charset.defaultCharset()).read();
}catch(Exception ex){
ex.printStackTrace();
}
}
// 尝试获取
public boolean tryAcqure(){
Jedis jedis = new Jedis("localhost",6379);
return (Long)jedis.eval(this.luascript,1,key,limit,expire) == 1L;
}
}

测试用例

package com.itheima.limiting;
import com.itheima.limiting.web.OrderRedisController;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;

import java.util.concurrent.CountDownLatch;
import java.util.concurrent.CyclicBarrier;
import java.util.concurrent.TimeUnit;
@SpringBootTest
class LimitingApplicationTests {
@Autowired
private OrderRedisController orderRedisController;
@Test
void contextLoads() throws Exception {
// 倒计数锁存器
CountDownLatch countDownLatch = new CountDownLatch(50);
// 循环屏障
CyclicBarrier cyclicBarrier = new CyclicBarrier(50);
for (int i = 0; i < 50; i++) {
new Thread(()->{
try{
cyclicBarrier.await();
}catch(Exception ex){
ex.printStackTrace();
}
try {
System.out.println(Thread.currentThread().getName() +
"===" + orderRedisController.makeorder6("aicode111"));
}catch (Exception ex){
ex.printStackTrace();
}
countDownLatch.countDown();
}).start();
}
try{
countDownLatch.await();
}catch(Exception ex){
ex.printStackTrace();
}
TimeUnit.SECONDS.sleep(1);
System.out.println(Thread.currentThread().getName() + "===" +
orderRedisController.makeorder6("aicode111"));
}
}

削峰填谷-平滑限流某个接口的请求数当消费端请求骤增时，可以为其配置排队等待的流控规则，以稳定的速度逐步处理这些请求，起到“削峰填谷”的效果，从而避免流量骤增造成系统负载过高。背景信息在实际应用中，收到的请求是没有规律的。例如：某应用的处理请求的能力是每秒 10 个。在某一秒，突然到来了 30 个请求，而接下来两秒，都没有请求到达。在这种情况下，如果直接拒绝 20 个请求，应用在接下来的两秒就会空闲。所以，需要把骤增的请求平均到一段时间内，让系统负载保持在请求处理水位之内，同时尽可能地处理更多请求。

上图中，红色的部分代表超出消息处理能力的部分。把红色部分的消息平均到之后的空闲时间去处理，这样既可以保证系统负载处在一个稳定的水位，又可以尽可能地处理更多消息。通过配置流控规则，可以达到消息匀速处理的效果。

了超时时间为 5s，则预计排队时长超过 5s 的处理任务将被直接拒绝。具体操作步骤，参见新建流控规则。

示意图如下：

问题

突发请求，流量整形，整形为匀速请求处理，（比如 5r/s 时间间隔200毫秒处理一个请求，平滑速率）.

解决方案：令牌桶算法

package com.itheima.limiting.web;
import com.google.common.util.concurrent.RateLimiter;
import com.itheima.limiting.limiter.JedisLuaLimiter;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class OrderGuavaRateLimitController {
// 平滑限流请求
RateLimiter rateLimiter = RateLimiter.create(4);
//@GetMapping("/makeorder7")
public String makeorder7() throws Exception{
if(!rateLimiter.tryAcquire()){

return (System.currentTimeMillis()/1000)+"抢购结束，下次在来! " ; } return (System.currentTimeMillis()/1000) + "恭喜，抢购成功"; } }

测试代码

package com.itheima.limiting;
import com.itheima.limiting.web.OrderGuavaRateLimitController;
import com.itheima.limiting.web.OrderRedisController;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.CyclicBarrier;
import java.util.concurrent.TimeUnit;
@SpringBootTest
class LimitingApplicationTests {
@Autowired
private OrderRedisController orderRedisController;
@Autowired
private OrderGuavaRateLimitController
orderGuavaRateLimitController;
@Test
void contextLoads() throws Exception {
// 倒计数锁存器
CountDownLatch countDownLatch = new CountDownLatch(50);
// 循环屏障
CyclicBarrier cyclicBarrier = new CyclicBarrier(50);
for (int i = 0; i < 50; i++) {
new Thread(()->{
try{
cyclicBarrier.await();
}catch(Exception ex){
ex.printStackTrace();
}
try {
//System.out.println(Thread.currentThread().getName() + "===" +
orderRedisController.makeorder6("aicode111"));
System.out.println(Thread.currentThread().getName()
+ "===" + orderGuavaRateLimitController.makeorder7());
}catch (Exception ex){
ex.printStackTrace();
}

自定义令牌桶算法
countDownLatch.countDown();
}).start();
}
try{
countDownLatch.await();
}catch(Exception ex){
ex.printStackTrace();
}
TimeUnit.SECONDS.sleep(1);
// System.out.println(Thread.currentThread().getName() + "===" +
orderRedisController.makeorder6("aicode111"));
System.out.println(Thread.currentThread().getName() + "===" +
orderGuavaRateLimitController.makeorder7());
}
}

自定义令牌桶算法

package com.itheima.limiting.limiter;
import java.util.Timer;
import java.util.TimerTask;
import java.util.concurrent.Semaphore;
public class MyRateLimiter implements AutoCloseable{
// 定义信号量 并发协同工具
private Semaphore semaphore;
// 限制数量
private int limit;
// 定时器
private Timer timer;
public MyRateLimiter(int limit){
super();
this.limit = limit;
this.semaphore = new Semaphore(limit);
this.timer = new Timer();
// 放入令牌的时间间隔
long period = 1000L/limit;
// 通过定时器。定时放入令牌
timer.scheduleAtFixedRate(new TimerTask() {
@Override
public void run() {
if(semaphore.availablePermits() < limit){
semaphore.release();
漏桶算法
SpringBoot 结合Aop完成限流策略
原理
首先解释下为何采用Redis作为限流组件的核心。
通俗地讲，假设一个用户（用IP判断）每秒访问某服务接口的次数不能超过10次，那么我们可以在
Redis中创建一个键，并设置键的过期时间为60秒。
当一个用户对此服务接口发起一次访问就把键值加1，在单位时间（此处为1s）内当键值增加到10的时
候，就禁止访问服务接口。PS:在某种场景中添加访问时间间隔还是很有必要的。我们本次不考虑间隔
时间，只关注单位时间内的访问次数。
需求
}
}
},period,period);
}
public void acquire() throws InterruptedException{
this.semaphore.acquire();
}
public boolean tryAcquire(){
return this.semaphore.tryAcquire();
}
public int availablePermits(){
return this.semaphore.availablePermits();
}
@Override
public void close(){
System.out.println("自动来关闭了..............");
this.timer.cancel();
}
}

1 @GetMapping("/makeorder")

2 public synchronized String makeOrder(){

3 long c = ++count;

4 if(c > limit){

5 return "抢购结束，下次在来! count = " + c; 6}

7return"恭喜，抢购成功，count = " + c; 8}

漏桶算法

SpringBoot 结合Aop完成限流策略

算法思想是：令牌以固定速率产生，并缓存到令牌桶中；令牌桶放满时，多余的令牌被丢弃；请求要消耗等比例的令牌才能被处理；令牌不够时，请求被缓存。

漏桶算法

算法思想是：水（请求）从上方倒入水桶，从水桶下方流出（被处理）；来不及流出的水存在水桶中（缓冲），以固定速率流出；水桶满后水溢出（丢弃）。这个算法的核心是：缓存请求、匀速处理、多余的请求直接丢弃。相比漏桶算法，令牌桶算法不同之处在于它不但有一只“桶”，还有个队列，这个桶是用来存放令牌的，队列才是用来存放请求的。从作用上来说，漏桶和令牌桶算法最明显的区别就是是否允许突发流量(burst)的处理，漏桶算法能够强行限制数据的实时传输（处理）速率，对突发流量不做额外处理；而令牌桶算法能够在限制数据的平均传输速率的同时允许某种程度的突发传输。 Nginx按请求速率限速模块使用的是漏桶算法，即能够强行保证请求的实时处理速度不会超过设置的阈值。 Nginx官方版本限制IP的连接和并发分别有两个模块： limit_req_zone 用来限制单位时间内的请求数，即速率限制,采用的漏桶算法 "leaky bucket"。 limit_req_conn 用来限制同一时间连接数，即并发限制。

limit_req_zone 参数配置

Syntax: limit_req zone=name [burst=number] [nodelay];
Default: —
Context: http, server, location
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;

第一个参数：$binary_remote_addr 表示通过remote_addr这个标识来做限制，“binary_”的目的
是缩写内存占用量，是限制同一客户端ip地址。
第二个参数：zone=one:10m表示生成一个大小为10M，名字为one的内存区域，用来存储访问的
频次信息。
第三个参数：rate=1r/s表示允许相同标识的客户端的访问频次，这里限制的是每秒1次，还可以有
比如30r/m的。

 limit_req zone=one burst=5 nodelay;

第一个参数：zone=one 设置使用哪个配置区域来做限制，与上面limit_req_zone 里的name对应。第二个参数：burst=5，重点说明一下这个配置，burst爆发的意思，这个配置的意思是设置一个大小为5的缓冲区当有大量请求（爆发）过来时，超过了访问频次限制的请求可以先放到这个缓冲区内。第三个参数：nodelay，如果设置，超过访问频次而且缓冲区也满了的时候就会直接返回503，如果没有设置，则所有请求会等待排队。

例子：

http {
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
server {
location /search/ {
limit_req zone=one burst=5 nodelay;
}
}

下面配置可以限制特定UA（比如搜索引擎）的访问：

limit_req_zone $anti_spider zone=one:10m rate=10r/s;
limit_req zone=one burst=100 nodelay;
if ($http_user_agent ~* "googlebot|bingbot|Feedfetcher-Google") {
set $anti_spider $http_user_agent;
}

其他参数

Syntax: limit_req_log_level info | notice | warn | error;
Default:
limit_req_log_level error;
Context: http, server, location

当服务器由于limit被限速或缓存时，配置写入日志。延迟的记录比拒绝的记录低一个级别。例子： limit_req_log_level notice 延迟的的基本是info。

Syntax: limit_req_status code;
Default:
limit_req_status 503;
Context: http, server, location

设置拒绝请求的返回值。值只能设置 400 到 599 之间。

ngx_http_limit_conn_module 参数配置

这个模块用来限制单个IP的请求数。并非所有的连接都被计数。只有在服务器处理了请求并且已经读取了整个请求头时，连接才被计数。

Syntax: limit_conn zone number;
Default: —
Context: http, server, location
limit_conn_zone $binary_remote_addr zone=addr:10m;
server {
location /download/ {
limit_conn addr 1;
}

一次只允许每个IP地址一个连接。

limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn_zone $server_name zone=perserver:10m;
server {
...
limit_conn perip 10;
limit_conn perserver 100;
}

可以配置多个limit_conn指令。例如，以上配置将限制每个客户端IP连接到服务器的数量，同时限制连接到虚拟服务器的总数。

Syntax: limit_conn_zone key zone=name:size;
Default: —
Context: http
limit_conn_zone $binary_remote_addr zone=addr:10m;

在这里，客户端IP地址作为关键。请注意，不是 $ remote_addr ，而是使用 $ binary_remote_addr 变量。 $ remote_addr 变量的大小可以从7到15个字节不等。存储的状态在32位平台上占用32或64字节的内存，在64位平台上总是占用64字节。对于IPv4地址， $ binary_remote_addr 变量的大小始终为4个字节，对于IPv6地址则为16个字节。存储状态在32位平台上始终占用32或64个字节，在64位平台上占用64个字节。一个兆字节的区域可以保持大约32000个32字节的状态或大约16000个64字节的状态。如果区域存储耗尽，服务器会将错误返回给所有其他请求。

Syntax: limit_conn_log_level info | notice | warn | error;
Default:
limit_conn_log_level error;
Context: http, server, location

当服务器限制连接数时，设置所需的日志记录级别。

Syntax: limit_conn_status code;
Default:
limit_conn_status 503;
Context: http, server, location

设置拒绝请求的返回值。

实战

实例一限制访问速率

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=2r/s;
server {
location / {
limit_req zone=mylimit;
}
}

上述规则限制了每个IP访问的速度为2r/s，并将该规则作用于根目录。如果单个IP在非常短的时间内并发发送多个请求，结果会怎样呢？我们使用单个IP在10ms内发并发送了6个请求，只有1个成功，剩下的5个都被拒绝。我们设置的速度是 2r/s，为什么只有1个成功呢，是不是Nginx限制错了？当然不是，是因为Nginx的限流统计是基于毫秒的，我们设置的速度是2r/s，转换一下就是500ms内单个IP只允许通过1个请求，从501ms开始才允许通过第二个请求。

实例二 burst缓存处理

我们看到，我们短时间内发送了大量请求，Nginx按照毫秒级精度统计，超出限制的请求直接拒绝。这在实际场景中未免过于苛刻，真实网络环境中请求到来不是匀速的，很可能有请求“突发”的情况，也就是“一股子一股子”的。Nginx考虑到了这种情况，可以通过burst关键字开启对突发请求的缓存处理，而不是直接拒绝。来看我们的配置：

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=2r/s;
server {
location / {
limit_req zone=mylimit burst=4;
}
}

我们加入了burst=4，意思是每个key(此处是每个IP)最多允许4个突发请求的到来。如果单个IP在10ms 内发送6个请求，结果会怎样呢？相比实例一成功数增加了4个，这个我们设置的burst数目是一致的。具体处理流程是：1个请求被立即处理，4个请求被放到burst队列里，另外一个请求被拒绝。通过burst参数，我们使得Nginx限流具备了缓存处理突发流量的能力。但是请注意：burst的作用是让多余的请求可以先放到队列里，慢慢处理。如果不加nodelay参数，队列里的请求不会立即处理，而是按照rate设置的速度，以毫秒级精确的速度慢慢处理。

实例三 nodelay降低排队时间

实例二中我们看到，通过设置burst参数，我们可以允许Nginx缓存处理一定程度的突发，多余的请求可以先放到队列里，慢慢处理，这起到了平滑流量的作用。但是如果队列设置的比较大，请求排队的时间就会比较长，用户角度看来就是RT变长了，这对用户很不友好。有什么解决办法呢？nodelay参数允许请求在排队的时候就立即被处理，也就是说只要请求能够进入burst队列，就会立即被后台worker处理，请注意，这意味着burst设置了nodelay时，系统瞬间的QPS可能会超过rate设置的阈值。nodelay 参数要跟burst一起使用才有作用。 延续实例二的配置，我们加入nodelay选项：

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=2r/s;
server {
location / {
limit_req zone=mylimit;
}
}

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=2r/s;
server {
location / {
limit_req zone=mylimit burst=4;
}
}

单个IP 10ms内并发发送6个请求，结果如下：跟实例二相比，请求成功率没变化，但是总体耗时变短了。这怎么解释呢？实例二中，有4个请求被放到burst队列当中，工作进程每隔500ms(rate=2r/s)取一个请求进行处理，最后一个请求要排队2s才会被处理；实例三中，请求放入队列跟实例二是一样的，但不同的是，队列中的请求同时具有了被处理的资格，所以实例三中的5个请求可以说是同时开始被处理的，花费时间自然变短了。但是请注意，虽然设置burst和nodelay能够降低突发请求的处理时间，但是长期来看并不会提高吞吐量的上限，长期吞吐量的上限是由rate决定的，因为nodelay只能保证burst的请求被立即处理，但Nginx 会限制队列元素释放的速度，就像是限制了令牌桶中令牌产生的速度。看到这里你可能会问，加入了nodelay参数之后的限速算法，到底算是哪一个“桶”，是漏桶算法还是令牌桶算法？当然还算是漏桶算法。考虑一种情况，令牌桶算法的token为耗尽时会怎么做呢？由于它有一个请求队列，所以会把接下来的请求缓存下来，缓存多少受限于队列大小。但此时缓存这些请求还有意义吗？如果server已经过载，缓存队列越来越长，RT越来越高，即使过了很久请求被处理了，对用户来说也没什么价值了。所以当token不够用时，最明智的做法就是直接拒绝用户的请求，这就成了漏桶算法。 示例四自定义返回值

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=2r/s;
server {
location / {
limit_req zone=mylimit burst=4 nodelay;
limit_req_status 598;
}
}

Java进阶

艾编教学笔记：高并发限流+分布式限流高并发限流技术揭秘

为什么要限流

目标

解决方案

SpringBoot结合Redis实现分布式限流演进

测试用例

测试代码

漏桶算法

limit_req_zone 参数配置

例子：

ngx_http_limit_conn_module 参数配置

实战

实例二 burst缓存处理

实例三 nodelay降低排队时间

相关

Java进阶专题(十四) 从电商系统角度研究多线程(上)

Java进阶专题(九) 设计模式之总结

Java进阶专题(十三) 探究JMM

Java进阶_网络编程

Java进阶_集合

Java进阶 JVM 内存与垃圾回收篇（一）

Java进阶篇——springboot2源码探究

标签