
/**
     * 能否执行
     * @return
     */
    public boolean canExecute(int maxNum,int shortPeriodPeriodMinute) {
        if ((getExecuteCount() + 1) <= maxNum
                && inShortPeriod(shortPeriodPeriodMinute) || !inShortPeriod(shortPeriodPeriodMinute)) {
            return true;
        }
        return false;
    }


  FlowControlRecord flowControlRecord = null;
 
            if (result != null) {
                flowControlRecord = JSON.parseObject(result, FlowControlRecord.class);
            }
            else {
                flowControlRecord = new FlowControlRecord();
            }
 
            // 不可执行直接抛错
            if (!flowControlRecord.canExecute(flowControlLimitConfig.getMaxNumInPeriod(), flowControlLimitConfig.getPeriodLengthMinute())) {
                throw new AlgorithmException(ErrorCodeEnum.TOO_MANY_TIME_IN_SHORT_PERIOD,
                        "key=" + key + ",execute time=" + (flowControlRecord.getExecuteCount() + 1) + ",maxCount=" + flowControlLimitConfig
                                .getMaxNumInPeriod()
                                + ",periodMinute="
                                + flowControlLimitConfig.getPeriodLengthMinute());
            }
 
            if (flowControlRecord.inShortPeriod(flowControlLimitConfig.getPeriodLengthMinute())) {
                //在时间内,积累计数
                flowControlRecord.setLastExecuteTime(new Date());
                flowControlRecord.setExecuteCount(flowControlRecord.getExecuteCount() + 1);
            }
            else {
                // 超过时间了重置.
                flowControlRecord.reset();
                flowControlRecord.setExecuteCount(1);
            }
 
            int leftSeconds = geLeftSeconds(flowControlLimitConfig, flowControlRecord).intValue();
            if (leftSeconds > 0) {
                redis.setex(keyFinal, leftSeconds, JSON.toJSONString(flowControlRecord));
            }

算法比较与选择

·固定窗口：

实现简单，但是过于粗暴，除非情况紧急，为了能快速止损眼前的问题可以作为临时应急的

方案。

·滑动窗口：

限流算法简单易实现，可以应对有少量突增流量场景。

·漏桶：

对于流量绝对均匀有很强的要求，资源的利用率上不是极致，但其宽进严出模式，保护系统的同

时还留有部分余量，是一个通用性方案。

令牌桶：

系统经常有突增流量，并尽可能的压榨服务的性能。

计数器法

固定窗口简单

计数器法是限流算法里最简单也是最容易实现的一种算法。比如我们规定，对于A接口来说，我们1分钟的访问次数不能超过100个。那么我们可以这么做：在一开始的时候，我们可以设置一个计数器counter，每当一个请求过来的时候，counter就加1，如果counter的值大于100并且该请求与第一个请求的间隔时间还在1分钟之内，那么说明请求数过多；如果该请求与第一个请求的间隔时间大于1分钟，且counter的值还在限流范围内，那么就重置 counter，具体算法的示意图如下：

在这里插入图片描述

这个算法虽然简单，但是有一个十分致命的问题，那就是临界问题，我们看下图：

从上图中我们可以看到，假设有一个恶意用户，他在0:59时，瞬间发送了100个请求，并且1:00又瞬间发送了100个请求，那么其实这个用户在 1秒里面，瞬间发送了200个请求。我们刚才规定的是1分钟最多100个请求，也就是每秒钟最多1.7个请求，用户通过在时间窗口的重置节点处突发请求，可以瞬间超过我们的速率限制。用户有可能通过算法的这个漏洞，瞬间压垮我们的应用。

聪明的朋友可能已经看出来了，刚才的问题其实是因为我们统计的精度太低。那么如何很好地处理这个问题呢？或者说，如何将临界问题的影响降低呢？我们可以看下面的滑动窗口算法。

滑动窗口 - 平滑

滑动窗口，又称rolling window。为了解决这个问题，我们引入了滑动窗口算法。如果学过TCP网络协议的话，那么一定对滑动窗口这个名词不会陌生。下面这张图，很好地解释了滑动窗口算法：

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

那么滑动窗口怎么解决刚才的临界问题的呢？我们可以看上图，0:59到达的100个请求会落在灰色的格子中，而1:00到达的请求会落在橘黄色的格子中。当时间到达1:00时，我们的窗口会往右移动一格，那么此时时间窗口内的总请求数量一共是200个，超过了限定的100个，所以此时能够检测出来触发了限流。

我再来回顾一下刚才的计数器算法，我们可以发现，计数器算法其实就是滑动窗口算法。只是它没有对时间窗口做进一步地划分，所以只有1格。

由此可见，当滑动窗口的格子划分的越多，那么滑动窗口的滚动就越平滑，限流的统计就会越精确。

漏桶算法异步, 拉长时间 - 有排队时间

先看看漏桶算法(Leaky bucket) - 需要额外的工作线程

如图所示,很明显从原来两个流量(12mbps 和2mbps)限流成了 3mbps.

实现:

一个比较简单实现是: n 个线程这种先把数据流量放置到一个队列里(或者一个接口拆成1个队列,分而治之), 然后另外一个线程从里面获取数据,请求.

应用场景:

异步化的调用比较好, 同步化的调用的话,就需要搞成类似 reactor 模式的形式,每个数据包需要有 seq_no 的概念(tcp,dubbo 异步传输). 非分布式的话,只需要使用futureTask就好了.

令牌桶 - 突刺限制最大流量 - fastfail

再看看令牌桶(Token bucket): 限制最大速度需要额外的令牌桶,只需要1个额外的线程添加令牌/甚至不用另外用完再还回去.

Guava官方文档-RateLimiter类

单机限流实现

- 使用Guava的RateLimiter进行限流控制

Guava是google提供的java扩展类库，其中的限流工具类RateLimiter采用的就是令牌桶算法。RateLimiter 从概念上来讲，速率限制器会在可配置的速率下分配许可证，如果必要的话，每个acquire() 会阻塞当前线程直到许可证可用后获取该许可证，一旦获取到许可证，不需要再释放许可证。通俗的讲RateLimiter会按照一定的频率往桶里扔令牌，线程拿到令牌才能执行，比如你希望自己的应用程序QPS不要超过1000，那么RateLimiter设置1000的速率后，就会每秒往桶里扔1000个令牌。例如我们需要处理一个任务列表，但我们不希望每秒的任务提交超过两个，此时可以采用如下方式：

有一点很重要，那就是请求的许可数从来不会影响到请求本身的限制（调用acquire(1) 和调用acquire(1000) 将得到相同的限制效果，如果存在这样的调用的话），但会影响下一次请求的限制，也就是说，如果一个高开销的任务抵达一个空闲的RateLimiter，它会被马上许可，但是下一个请求会经历额外的限制，从而来偿付高开销任务。注意：RateLimiter 并不提供公平性的保证。

四、使用Semphore进行并发流控限流 [令牌桶法,但使用完还回去.]

Java 并发库的Semaphore 可以很轻松完成信号量控制，Semaphore可以控制某个资源可被同时访问的个数，通过 acquire() 获取一个许可，如果没有就等待，而 release() 释放一个许可。单个信号量的Semaphore对象可以实现互斥锁的功能，并且可以是由一个线程获得了“锁”，再由另一个线程释放“锁”，这可应用于死锁恢复的一些场合。下面的Demo中申明了一个只有5个许可的Semaphore，而有20个线程要访问这个资源，通过acquire()和release()获取和释放访问许可：

最后：进行限流控制还可以有很多种方法，针对不同的场景各有优劣，例如通过AtomicLong计数器控制、使用MQ消息队列进行流量消峰等等。

集群限流

- 依赖redis

集群限流or单机限流? 蚂蚁Guardian / 业界Hystrix

同时，蚂蚁还提供了一个叫 Guardian 的组件，通过它可以实现对线上服务的熔断限流的自动保护机制，类似 Netflix 提供的 Hystrix 组件，大家有兴趣可以去了解一下。

干货 | 余额宝大规模服务化的技术创新 - 知乎

本文内容由网友自发贡献，转载请注明出处：【wpsshop博客】

限流算法的理解和应用场景和实现_semphore与ratelimter的优缺点

四种 计数器,漏桶,令牌桶,信号量

一次实战