大家好，我是从古代穿越过来的美男子：架构摆渡人。我将把我的武功秘籍全部传授与你们，觉得有用请分享给身边的朋友。来个三连吧，感谢各位！另外我还在B站录制了《真实订单业务，亿级数据带你实战分库分表》的实战课程，记得去学习哦！

上篇文章《为什么大公司都要做流量治理？》跟大家聊了下做流量治理的真正目的是什么。如果你要开发一个流量治理的平台或者一个限流的框架，那么必不可少的就是要选择一种合适的限流算法。本篇文章就跟大家聊聊目前常用的限流算法有哪些。

计数器

计数器是最简单，最直接明了的限流算法。说白了就是进行数字累加操作，也就是count++ 这你总能看懂吧！

单机限流可以直接使用LongAdder或者AtomicLong这些原子类进行计数操作即可。用Semaphore也可以，Semaphore内部本身就是计数器的方式实现。

集群限流可以使用Redis的incr进行计数累加即可，用其他的存储也可以，核心就是要有集中存储计数的地方。

计数器算法也分为两种形式，一种是有时间段的限制，另一种是没有时间段的限制。

有时间段限制

有时间段限制就是你限流的时长是多少，一般我们都会以秒为单位。比如限制QPS为1000。

有时间限制会存在一个临界区的问题，假设第1秒中的第999毫秒的时候，来了800个请求，这个时候是没有超过1000 QPS的限制。然后第2秒的1毫秒来了800个请求，相隔几毫秒，很有可能前面的请求还没执行完成，这么又来了，其实这个时候的请求已经超出了你系统能够承受的范围了，也就失去了限流的效果。

如果非得要用有时间限制的计数器算法，那么可以将时间单位调的越小越好。当然还有其他的算法能够解决这个临界区的问题，下面会介绍到。

无时间段限制

无时间段限制就不会存在临界区的问题，请求进来数量加一，请求结束数量减一。将并发量最高永远限制在你想要的范围内。跟Semaphore是一样的作用。

这个其实跟我们去饭店吃饭一样，饭店总共10个座位，坐满了你就得在外面等着叫号。如果有客人吃完离开了，空了一个座位出来，下一个客人才能进去。这样就能永远保证进去的人不超过饭店的座位数量，也在厨师和服务员能够服务的范围之内。

伪代码示列：

@Slf4j
public class RatelimitFilter implements Filter {


    private AtomicLong atomicLong = new AtomicLong();


    @Override
    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
        HttpServletRequest request = (HttpServletRequest)servletRequest;
        try {
            long currentQps = atomicLong.incrementAndGet();
            log.info("当前QPS: {}", currentQps);
            if (currentQps > 1) {
                throw new RuntimeException("限流中。。。。");
            }
            try {
                // 模拟业务耗时
                TimeUnit.SECONDS.sleep(2);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        } finally {
            atomicLong.decrementAndGet();
        }
    }


}

滑动窗口

了解滑动窗口前先需要了解下固定窗口，固定窗口比较简单，也就相当于固定大小。比如限制1秒内的访问次数，那么这个1秒就是一个固定的时间窗口。

滑动窗口可以将固定窗口再进行细分成多个窗口，比如将1秒中的固定窗口细分成5个窗口，那么每个窗口的时间就是200毫秒。

假设每秒钟限流100，在201ms-1000ms之间的时候来了99个请求，不满足限流条件，放行。在第2秒的100ms的时候来了999个请求，这个时候多余的请求会被限制。当前窗口的范围是1秒的201ms~2秒的200ms。

通过滑动窗口算法，同时也能解决了上面计数算法临界区的问题。窗口是一直滑动的，计算的数量也不是固定时间内的，而是随着窗口的滑动一直在变化。

漏桶

漏桶算法能够很好的保证稳定性，可以将突发的高流量以固定的速度流出来保证稳定性。

我记得小时候，家里每年都会酿米酒，甜甜的米酒很好喝。当然我们不是来讲米酒好不好喝的问题，而是要讲解漏洞算法。那么漏桶算法跟米有又有什么联系呢？

酿好的米酒会装在酒坛里面，有时候村里的其他人需要用到米酒的时候，如果自己家里没有酿的话就会去别人家买，一般都是拿一个瓶子来装，比如我们的可乐瓶子。

但是可乐瓶子的入口很小，直接往里面倒酒的话很容易洒出来。这个时候就有一个装酒的漏斗，这个东西就跟我们今天要讲的漏桶一样，下面很小，上面很大。酒就相当于流量，倒入这个漏桶里面，然后会从下面很小的口流出来，这个速度是固定的，这么说相信大家一定明白了什么是漏桶算法吧。

漏桶算法的优点是能够以固定的速率去控制流量，稳定性比较好。缺点就是无法应对突发流量的来袭，我们来分析具体的分析下这个缺点。

假设你的漏桶出口固定了每秒钟只能通过100个请求，如果此时有150个请求，无论你后方的系统能不能抗住这150个请求，通过漏桶算法都会将另外50个请求进行拦截，只能等前面的100个请求结束后才能继续放行剩下的50个请求。

那么有没有什么算法既能做流量控制，又能应对突发流量的场景呢？接下来为你介绍令牌桶算法。

令牌桶

令牌桶算法用比较官方的术语来解释就是：一个有固定容量的桶，按一定的速度往桶里面放令牌，如果桶里面装不下令牌了就不放了。有请求进来就去桶里面获取对应的令牌，能拿到令牌就可以通过，拿不到就拒绝，也就是限流了。

我们还是用生活中的方式来解释下令牌桶的原理，有天你带着你的女朋友去吃自助餐，那些吃的你们可以随便拿，如果拿完了，是不是就得等待餐厅重新供应了才行，这就是限流了。同时，餐厅会定时的供应新的食物，食物供应上了，你能够拿到了那就是放行，相当于拿到了令牌。

有令牌如下图所示：

无令牌如下图所示：

总结

本文对目前主流的限流算法进行了讲解，相信大家有了一个初步的认识。这些算法在面试中也经常被问到，同时我也是通过各种生活中的案例来举例，希望大家能够彻底的理解这些算法的原理。

大家好，我是从古代穿越过来的美男子：架构摆渡人。我将把我的武功秘籍全部传授与你们，觉得有用请分享给身边的朋友。来个三连吧，感谢各位！另外我还在B站录制了《真实订单业务，亿级数据带你实战分库分表》的实战课程，记得去学习哦！