系列地址：https://gamwatcher.blog.csdn.net/article/details/124603278

1、为什么限流 

北京清早上班的地铁大家应该都有了解，在地铁站外面有一圈一圈的铁栏杆，这是为什么呐？为了限流！

试想一下，如果大家一下全都挤进地铁站，但是车的运载能力是有限的，超过了就会出现安全问题，到时候地铁站就没办法运行了，会造成整个地铁系统都崩溃了。

同样，程序也是这样。在线上提供服务的时候，有时候有突发流量，如何处理才能保证整个系统的稳定性，限流方案是一定要有的。

2、限流算法

2.1 漏桶算法

漏桶的的解决思路是最直接的，也是最简单的，就是请求到来之后先判断是否能够服务，判断服务的标准就是时间尺度，

简单理解，就是如果1s服务一个请求，如果最多服务10个，超过了就直接解决，没超过就放过去。

简单实现一个

public class Bucket {
    private int capacity;  // 桶的容量
    private int water;     // 当前水量
    private long lastLeakTime;  // 上一次漏水的时间

    public Bucket(int capacity) {
        this.capacity = capacity;
        this.water = 0;
        this.lastLeakTime = System.currentTimeMillis();
    }

    // 尝试加水，返回是否加水成功
    public synchronized boolean tryAddWater(int amount) {
        long now = System.currentTimeMillis();
        // 先漏水
        int leakedWater = (int) ((now - lastLeakTime) * 1.0 / 1000 * capacity);
        water = Math.max(0, water - leakedWater);
        lastLeakTime = now;
        // 再加水
        if (water + amount <= capacity) {
            water += amount;
            return true;
        }
        return false;
    }
}

2.2 令牌桶算法

令牌桶算法的原理也比较简单，我们可以理解成医院的挂号看病，只有拿到号以后才可以进行诊病。

系统会维护一个令牌（ token ）桶，以一个恒定的速度往桶里放入令牌（ token ），这时如果有请求进来想要被处理，则需要先从桶里获取一个令牌（ token ），当桶里没有令牌（ token ）可取时，则该请求将被拒绝服务。令牌桶算法通过控制桶的容量、发放令牌的速率，来达到对请求的限制。

注：Guava RateLimiter就是令牌桶实现

2.3 计数算法

在接口中收到请求之后计数+1，在接口处理完成之后再计数-1，通过控制总的数据达到限流的目的

2.4 滑动窗口算法

如果学过TCP网络协议的话，那么一定对滑动窗口这个名词不会陌生，

整个矩形框表示一个时间窗口，一个时间窗口就是一分钟。然后我们将时间窗口进行划分，比如图中，我们就将滑动窗口划成了6格，所以每格代表的是10秒钟。每过10秒钟，我们的时间窗口就会往右滑动一格。每一个格子都有自己独立的计数器counter，比如当一个请求在0:35秒的时候到达，那么0:30~0:39对应的counter就会加1。

2.5 总结

• 令牌桶算法：获取令牌的请求才会被处理，其他请求要么排队要么直接被丢弃，桶存放指定的令牌数
• 漏桶算法：漏桶是将请求放到桶里，若是桶满了，其他请求将被丢弃，桶里的请求以恒定的速率从桶内流出
• 滑动窗口：当时间窗口的跨度越长，限流效果越平滑；

3、限流插入点

3.1、filter过滤器

Spring Boot 提供了一个过滤器框架，可以通过编写自定义过滤器来实现限流。该过滤器可以根据请求的频率、IP、用户等信息进行限流，从而保护应用程序免受恶意攻击和过度使用的影响。

public class RateLimitFilter implements Filter {
    // 每秒最大请求数
    private final double permitsPerSecond = 10;
    private final RateLimiter rateLimiter = RateLimiter.create(permitsPerSecond);

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        if (rateLimiter.tryAcquire()) {
            // 放行请求
            chain.doFilter(request, response);
        } else {
            // 返回限流错误
            HttpServletResponse httpServletResponse = (HttpServletResponse) response;
            httpServletResponse.setStatus(HttpStatus.TOO_MANY_REQUESTS.value());
        }
    }
}

@Configuration
public class WebConfig {
    @Bean
    public FilterRegistrationBean<RateLimitFilter> rateLimitFilter() {
        FilterRegistrationBean<RateLimitFilter> registrationBean = new FilterRegistrationBean<>();
        registrationBean.setFilter(new RateLimitFilter());
        registrationBean.addUrlPatterns("/*");
        registrationBean.setOrder(1);
        return registrationBean;
    }
}

3.2 、拦截器（Interceptor）

创建一个 RateLimitInterceptor 类，并实现 HandlerInterceptor 接口。在 preHandle 方法中，使用 Redis 的 incr 方法对当前请求的 IP 地址进行计数，并将计数结果与预设的阈值进行比较。如果计数结果超过阈值，则返回 false，表示请求被限流。

public class RateLimitInterceptor implements HandlerInterceptor {

    private RedisTemplate<String, Object> redisTemplate;

    public RateLimitInterceptor(RedisTemplate<String, Object> redisTemplate) {
        this.redisTemplate = redisTemplate;
    }

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        String ip = request.getRemoteAddr();
        String key = "rate_limit:" + ip;
        Long count = redisTemplate.opsForValue().increment(key, 1);
        if (count != null && count > 10) {
            response.getWriter().write("请求过于频繁，请稍后再试！");
            return false;
        }
        return true;
    }

    // 在 afterCompletion 方法中清除计数器
    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
        String ip = request.getRemoteAddr();
        String key = "rate_limit:" + ip;
        redisTemplate.delete(key);
    }
}

然后，在 WebMvcConfigurer 中注册拦截器：

@Configuration
public class WebMvcConfig implements WebMvcConfigurer {

    private RedisTemplate<String, Object> redisTemplate;

    public WebMvcConfig(RedisTemplate<String, Object> redisTemplate) {
        this.redisTemplate = redisTemplate;
    }

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new RateLimitInterceptor(redisTemplate)).addPathPatterns("/**");
    }
}

3.3、AOP

AOP这个基本上是能解决所有的了，面向方法做个切面，至于切面中实现怎么样的业务逻辑根据限流的具体算法实现，

3.4 总结

过滤器，拦截器拦截的是URL。AOP拦截的是类的元数据(包、类、方法名、参数等)。

4、限流工具

4.1 Guava RateLimiter

这个是谷歌提供的一个限流的类，看到实现就知道做什么了，

RateLimiter是一个基于令牌桶算法实现的限流器，常用于控制网站的QPS。与Semaphore不同，Semaphore控制的是某一时刻的访问量，RateLimiter控制的是某一时间间隔的访问量。

public void testAcquire() {
      // 创建一个限流器，参数代表每秒生成的令牌数
      RateLimiter limiter = RateLimiter.create(1);

      for(int i = 1; i < 10; i = i + 2 ) {
          // limiter.acquire以阻塞的方式获取令牌。
          // 当然也可以通过tryAcquire(int permits, long timeout, TimeUnit unit)来设置等待超时时间的方式获取令牌，
          // 如果超timeout为0，则代表非阻塞，获取不到立即返回
          double waitTime = limiter.acquire(i);
          System.out.println("cutTime=" + System.currentTimeMillis() + " acq:" + i + " waitTime:" + waitTime);
      }
  }

4.2 消息队列

消息队列限流是指在服务器面临大量流量时，将请求放到消息队列进行削峰，不至于一下全部到应用服务器。

这个应用场景比较多的在电商活动中，比如秒杀，抢购等场景中。将抢购中放到消息队列中，应用服务器慢慢处理。

基本上任何一个消息队列都有限流的功能

4.3 Zoo 和redis

zoo和redis 用来限流的主要原理是分布式锁的实现，通过对同一对象操作，实现分布式锁，计数可以实现分布式限流

4.4 框架 Sentinel

Sentinel 是面向分布式服务架构的高可用流量防护组件，主要以流量为切入点，从限流、流量整形、熔断降级、系统负载保护、热点防护等多个维度来帮助开发者保障微服务的稳定性。

5、总结

限流的目的是保证系统的可用

限流的原则是使流量稳定通过

限流的插入方式根据自己项目进行选择，简单的就是好的

如果自己实现，可以简单组合下，并没有太多难度

19个新媒体大类（视频、音频、直播、社群、微博、社区团购、行业垂直、知识付费、信息资讯、传统电商、社交交友、运动健身、资讯搜索、地图导航、旅游、网站、浏览器、本地生活、其他热门App），引导新媒体全网运营；17个章带你打通全网数字化营销。

一本新媒体百科全书，让你用一本书实现新媒体全网运营一本通！