文章目录
1.计数器
计数器是最简单，最直接明了的限流算法。说白了就是进行数字累加操作，也就是count++ 这你总能看懂吧！
单机限流可以直接使用LongAdder或者AtomicLong这些原子类进行计数操作即可。用Semaphore也可以，Semaphore内部本身就是计数器的方式实现。
集群限流可以使用Redis的incr进行计数累加即可，用其他的存储也可以，核心就是要有集中存储计数的地方。
计数器算法也分为两种形式，一种是有时间段的限制，另一种是没有时间段的限制。
1.1 时间段的限制
有时间段限制就是你限流的时长是多少，一般我们都会以秒为单位。比如限制QPS为1000。
有时间限制会存在一个临界区的问题，假设第1秒中的第999毫秒的时候，来了800个请求，这个时候是没有超过1000 QPS的限制。然后第2秒的1毫秒来了800个请求，相隔几毫秒，很有可能前面的请求还没执行完成，这么又来了，其实这个时候的请求已经超出了你系统能够承受的范围了，也就失去了限流的效果。
如果非得要用有时间限制的计数器算法，那么可以将时间单位调的越小越好。当然还有其他的算法能够解决这个临界区的问题，下面会介绍到。
1.2 无时间段限制
无时间段限制就不会存在临界区的问题，请求进来数量加一，请求结束数量减一。将并发量最高永远限制在你想要的范围内。跟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();
}
}
}
2.滑动窗口
了解滑动窗口前先需要了解下固定窗口，固定窗口比较简单，也就相当于固定大小。比如限制1秒内的访问次数，那么这个1秒就是一个固定的时间窗口。
滑动窗口可以将固定窗口再进行细分成多个窗口，比如将1秒中的固定窗口细分成5个窗口，那么每个窗口的时间就是200毫秒。
假设每秒钟限流100，在201ms-1000ms之间的时候来了99个请求，不满足限流条件，放行。在第2秒的100ms的时候来了999个请求，这个时候多余的请求会被限制。当前窗口的范围是1秒的201ms~2秒的200ms。
通过滑动窗口算法，同时也能解决了上面计数算法临界区的问题。窗口是一直滑动的，计算的数量也不是固定时间内的，而是随着窗口的滑动一直在变化。
3.漏桶
漏桶算法能够很好的保证稳定性，可以将突发的高流量以固定的速度流出来保证稳定性。
我记得小时候，家里每年都会酿米酒，甜甜的米酒很好喝。当然我们不是来讲米酒好不好喝的问题，而是要讲解漏洞算法。那么漏桶算法跟米有又有什么联系呢？
酿好的米酒会装在酒坛里面，有时候村里的其他人需要用到米酒的时候，如果自己家里没有酿的话就会去别人家买，一般都是拿一个瓶子来装，比如我们的可乐瓶子。
但是可乐瓶子的入口很小，直接往里面倒酒的话很容易洒出来。这个时候就有一个装酒的漏斗，这个东西就跟我们今天要讲的漏桶一样，下面很小，上面很大。酒就相当于流量，倒入这个漏桶里面，然后会从下面很小的口流出来，这个速度是固定的，这么说相信大家一定明白了什么是漏桶算法吧。
漏桶算法的优点是能够以固定的速率去控制流量，稳定性比较好。缺点就是无法应对突发流量的来袭，我们来分析具体的分析下这个缺点。
假设你的漏桶出口固定了每秒钟只能通过100个请求，如果此时有150个请求，无论你后方的系统能不能抗住这150个请求，通过漏桶算法都会将另外50个请求进行拦截，只能等前面的100个请求结束后才能继续放行剩下的50个请求。
那么有没有什么算法既能做流量控制，又能应对突发流量的场景呢？接下来为你介绍令牌桶算法。
4.令牌桶
令牌桶算法用比较官方的术语来解释就是：一个有固定容量的桶，按一定的速度往桶里面放令牌，如果桶里面装不下令牌了就不放了。有请求进来就去桶里面获取对应的令牌，能拿到令牌就可以通过，拿不到就拒绝，也就是限流了。
我们还是用生活中的方式来解释下令牌桶的原理，有天你带着你的女朋友去吃自助餐，那些吃的你们可以随便拿，如果拿完了，是不是就得等待餐厅重新供应了才行，这就是限流了。同时，餐厅会定时的供应新的食物，食物供应上了，你能够拿到了那就是放行，相当于拿到了令牌。
有令牌如下图所示：
无令牌如下图所示：
5.总结
本文对目前主流的限流算法进行了讲解，相信大家有了一个初步的认识。这些算法在面试中也经常被问到，同时我也是通过各种生活中的案例来举例，希望大家能够彻底的理解这些算法的原理。