java各层级限流对比,面试官说：来谈谈限流-从概念到实现，一问你就懵逼了？...

后端服务的接口都是有访问上限的，如果外部qps或并发量超过了访问上限会导致应用瘫痪。所以一般都会对接口调用加上限流保护，防止超出预期的请求导致系统故障。

从限流类型来说一般来说分为两种:并发数限流和qps限流，并发数限流就是限制同一时刻的最大并发请求数量，qps限流指的是限制一段时间内发生的请求个数。

从作用范围的层次上来看分单机限流和分布式限流，前者是针对单机的，后者是针对集群的，他们的思想都是一样的，只不过是范围不一样，本文分析的都是单机限流。

接下来我们看看并发数限流和qps限流。

并发数限流

并发数限流限制的是同一时刻的并发数，所以不考虑线程安全的话，我们只要用一个int变量就能实现，伪代码如下：

int maxrequest=100;

int nowrequest=0;

public void request(){

if(nowrequest>=maxrequest){

return ;

}

nowrequest++;

//调用接口

try{

invokexxx();

}finally{

nowrequest--;

}

显然，上述实现会有线程安全的问题，最直接的做法是加锁：

int maxrequest=100;

int nowrequest=0;

public void request(){

if(nowrequest>=maxrequest){

return ;

}

synchronized(this){

if(nowrequest>=maxrequest){

return ;

}

nowrequest++;

}

//调用接口

try{

invokexxx();

}finally{

synchronized(this){

nowrequest--;

}

当然也可以用atomicinteger实现：

int maxrequest=100;

atomicinteger nowrequest=new atomicinteger(0);

public void request(){

for(;;){

int currentreq=nowrequest.get();

if(currentreq>=maxrequest){

return;

}

if(nowrequest.compareandset(currentreq,currentreq+1)){

break;

}

//调用接口

try{

invokexxx();

}finally{

nowrequest.decrementandget();

}

熟悉jdk并发包的同学会说干嘛这么麻烦，这不就是信号量(semaphore)做的事情吗？对的，其实最简单的方法就是用信号量来实现：

int maxrequest=100;

semaphore reqsemaphore = new semaphore(maxrequest);

public void request(){

if(!reqsemaphore.tryacquire()){

return ;

}

//调用接口

try{

invokexxx();

}finally{

reqsemaphore.release();

}

条条大路通罗马，并发数限流比较简单，一般来说用信号量就好。

qps限流

qps限流限制的是一段时间内(一般指1秒)的请求个数。

计数器法

最简单的做法用一个int型的count变量做计数器：请求前计数器+1，如超过阈值并且与第一个请求的间隔还在1s内，则限流。

伪代码如下：

int maxqps=100;

int count;

long timestamp=system.currenttimemillis();

long interval=1000;

public synchronized boolean grant(){

long now=system.currenttimemillis();

if(now

count++;

return count

}else{

timestamp=now;

count=1;

return true;

}

该种方法实现起来很简单，但其实是有临界问题的，假如在第一秒的后500ms来了100个请求，第2秒的前500ms来了100个请求，那在这1秒内其实最大qps为200。如下图：

计数器法会有临界问题，主要还是统计的精度太低，这点可以通过滑动窗口算法解决

滑动窗口

我们用一个长度为10的数组表示1秒内的qps请求，数组每个元素对应了相应100ms内的请求数。用一个sum变量代码当前1s的请求数。同时每隔100ms将淘汰过期的值。

伪代码如下：

int maxqps=100;

atomicinteger[] count=new atomicinteger[10];

long timestamp=system.currenttimemillis();

long interval=1000;

atomicinteger sum;

volatile int index;

public void init(){

for(int i=0;i

count[i]=new atomicinteger(0);

}

sum=new atomicinteger(0);

}

public synchronized boolean grant(){

count[index].incrementandget();

return sum.incrementandget()

}

//每100ms执行一次

public void run(){

index=(index+1)%count.length;

int val=count[index].getandset(0);

sum.addandget(-val);

}

滑动窗口的窗口越小，则精度越高，相应的资源消耗也更高。

漏桶算法

漏桶算法思路是，有一个固定大小的桶，水(请求)忽快忽慢的进入到漏桶里，漏桶以一定的速度出水。当桶满了之后会发生溢出。

在维基百科上可以看到，漏桶算法有两种实现，一种是as a meter，另一种是as a queue。网上大多数文章都没有提到其有两种实现，且对这两种概念混乱。

as a meter

第一种实现是和令牌桶等价的，只是表述角度不同。

伪代码如下：

long timestamp=system.currenttimemillis();//上一次调用grant的时间

int bucketsize=100;//桶大小

int rate=10;//每ms流出多少请求

int count;//目前的水量

public synchronized boolean grant(){

long now = system.currenttimemillis();

if(now>timestamp){

count = math.max(0,count-(now-timestamp)*rate);

timestamp = now;

}

if(count+1<=bucketsize){

count++;

return true;

}else{

return false;

}

该种实现允许一段时间内的突发流量，比如初始时桶中没有水，这时1ms内来了100个请求，这100个请求是不会被限流的，但之后每ms最多只能接受10个请求(比如下1ms又来了100个请求，那其中90个请求是会被限流的)。

其达到的效果和令牌桶一样。

as a queue

第二种实现是用一个队列实现，当请求到来时如果队列没满则加入到队列中，否则拒绝掉新的请求。同时会以恒定的速率从队列中取出请求执行。

伪代码如下：

queue queue=new linkedblockingqueue(100);

int gap;

int rate;

public synchronized boolean grant(request req){

if(!queue.offer(req)){return false;}

}

// 单独线程执行

void consume(){

while(true){

for(int i=0;i

//执行请求

request req=queue.poll();

if(req==null){break;}

req.dorequest();

}

thread.sleep(gap);

}

对于该种算法，固定的限定了请求的速度，不允许流量突发的情况。

比如初始时桶是空的，这时1ms内来了100个请求，那只有前10个会被接受，其他的会被拒绝掉。注意与上文中as a meter实现的区别。

**不过，当桶的大小等于每个ticket流出的水大小时，第二种漏桶算法和第一种漏桶算法是等价的。**也就是说,as a queue是as a meter的一种特殊实现。如果你没有理解这句话，你可以再看看上面as a meter的伪代码，当bucketsize==rate时，请求速度就是恒定的，不允许突发流量。

令牌桶算法

令牌桶算法的思想就是，桶中最多有n个令牌，会以一定速率往桶中加令牌，每个请求都需要从令牌桶中取出相应的令牌才能放行，如果桶中没有令牌则被限流。