漏桶算法和令牌桶算法的区别

漏桶算法与令牌桶算法在表面看起来类似，很容易将两者混淆。但事实上，这两者具有截然不同的特性，且为不同的目的而使用。漏桶算法与令牌桶算法的区别在于：漏桶算法能够强行限制数据的传输速率。令牌桶算法能够在限制数据的平均传输速率的同时还允许某种程度的突发传输。需要说明的是：在某些情况下，漏桶算法不能够有效地使用网络资源。因为漏桶的漏出速率是固定的，所以即使网络中没有发生拥塞，漏桶算法也不能使某一个单独的数据流达到端口速率。因此，漏桶算法对于存在突发特性的流量来说缺乏效率。而令牌桶算法则能够满足这些具有突发特性的流量。通常，漏桶算法与令牌桶算法结合起来为网络流量提供更高效的控制

1|0漏桶限流算法的原理

以固定速率从桶中流出水滴，以任意速率往桶中放入水滴，桶容量大小是不会发生改变的。

流入：以任意速率往桶中放入水滴。

流出：以固定速率从桶中流出水滴。

水滴：是唯一不重复的标识。

因为桶中的容量是固定的，如果流入水滴的速率>流出的水滴速率，桶中的水滴可能会溢出。那么溢出的水滴请求都是拒绝访问的，或者直接调用服务降级方法。前提是同一时刻

2|0令牌桶算法(Token)

令牌桶分为2个动作，动作1(固定速率往桶中存入令牌)、动作2(客户端如果想访问请求，先从桶中获取token)。guava 提供的RateLimiter类来进行限流处理。

1.传统的方式整合RateLimiter 有很大的缺点：代码重复量特别大，而且本身不支持注解方式。 2.如果限流代码可以放在网关中，相当于针对所有的服务接口都实现限流(可以使用排除法进行排除不进行限流的方法)，维护性不是很强。 3.正常的互联网公司项目，不是所有的服务接口都需要实现限流方法的，一般只真针对于大流量接口。比如：秒杀抢购、12306抢票等。 4.可以手动封装一个RateLimiter类 注解来解决这个方法

以规定的速率往令牌桶中放入 token，用户请求必须获取到令牌桶中的 token才可以访问我们的业务逻辑方法，如果没有从令牌桶中获取到 token ，拒绝访问。
在高并发情况下，如果我们的请求过多 超出了令牌桶生成令牌的速度，这时候请求就会被驳回，提示请稍后重试！
优势：能够控制请求的速率。

限流的目的：为了保护服务，避免服务宕机。

3|0使用RateLimiter实现令牌桶限流

1,RateLimiter是guava提供的基于令牌桶算法的实现类，可以非常简单的完成限流特技，并且根据系统的实际情况来调整生成token的速率。
通常可应用于抢购限流防止冲垮系统；限制某接口、服务单位时间内的访问量，譬如一些第三方服务会对用户访问量进行限制；限制网速，单位时间内只允许上传下载多少字节等。

guava的maven依赖

<dependency>
     <groupId>com.google.guava</groupId>
     <artifactId>guava</artifactId>
     <version>25.1-jre</version>
 </dependency>

2,令牌桶的原理，有一个独立线程一直以一个固定的速率往桶中存放令牌

   客户端去桶中获取令牌，获取到令牌，就可以访问，获取不到，说明请求过多，需要服务降级。

3，

package com.aiyuesheng.controller;

import java.util.concurrent.TimeUnit;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

import com.aiyuesheng.hystrix.OrderHystrixCommand;
import com.aiyuesheng.service.OrderService;
import com.aiyuesheng.utils.LimitService;
import com.alibaba.fastjson.JSONObject;
import com.google.common.util.concurrent.RateLimiter;

@RestController
public class Index {// 令牌桶：1.0 表示 每秒中生成1个令牌存放在桶中
    RateLimiter rateLimiter = RateLimiter.create(1.0);

    @Autowired
    private OrderService orderService;
//令牌桶限流
    @RequestMapping("/searchCustomerInfoByRateLimiter")
    public Object searchCustomerInfoByRateLimiter() {
        // 1.限流判断
        // 如果在0.5秒内 没有获取不到令牌的话，则会一直等待
        System.out.println("生成令牌等待时间:" + rateLimiter.acquire());
        boolean acquire = rateLimiter.tryAcquire(500, TimeUnit.MILLISECONDS); // 每次发送请求，愿意等待0.5秒，如果设为1秒，每次都能查询成功，因为没秒中都会放入一个令牌到桶中
        if (!acquire) {
            System.out.println("稍后再试！");
            return "稍后再试！";
        }
        // 2.如果没有达到限流的要求,直接调用接口查询
        System.out.println(orderService.searchCustomerInfo());
        return orderService.searchCustomerInfo();
    }

}

 

4|0总结

常用的限流算法有两种：漏桶算法和令牌桶算法。

漏桶算法思路很简单，水（请求）先进入到漏桶里，漏桶以一定的速度出水，当水流入速度过大会直接溢出，可以看出漏桶算法能强行限制数据的传输速率

对于很多应用场景来说，除了要求能够限制数据的平均传输速率外，还要求允许某种程度的突发传输。这时候漏桶算法可能就不合适了，令牌桶算法更为适合。如图2所示，令牌桶算法的原理是系统会以一个恒定的速度往桶里放入令牌，而如果请求需要被处理，则需要先从桶里获取一个令牌，当桶里没有令牌可取时，则拒绝服务

并不能说明令牌桶一定比漏洞好，她们使用场景不一样。令牌桶可以用来保护自己，主要用来对调用者频率进行限流，为的是让自己不被打垮。所以如果自己本身有处理能力的时候，如果流量突发（实际消费能力强于配置的流量限制），那么实际处理速率可以超过配置的限制。而漏桶算法，这是用来保护他人，也就是保护他所调用的系统。主要场景是，当调用的第三方系统本身没有保护机制，或者有流量限制的时候，我们的调用速度不能超过他的限制，由于我们不能更改第三方系统，所以只有在主调方控制。这个时候，即使流量突发，也必须舍弃。因为消费能力是第三方决定的。

总结起来：如果要让自己的系统不被打垮，用令牌桶。如果保证被别人的系统不被打垮，用漏桶算法。