1 什么是限流算法
限流算法是一种用于限制流量请求的频率或速率的算法，其目的是在高并发或大流量请求的情况下，保护系统服务的安全性和可用性。限流算法可以应对热点业务带来的突发请求、调用方bug导致的突发请求以及恶意攻击请求等情况。是一种系统保护策略，主要是避免在流量高峰导致系统被压垮，造成系统不可用的问题。
2 常见的限流算法
（1）计数器限流
一般用在单一维度的访问频率限制上，比如短信验证码每隔60s 只能发送一次，或者接口调用次数等。它的实现方法很简单，每调用一次就加 1，处理结束以后减一。
计数器限流算法的实现原理是在一个时间窗口内，每调用一次就增加计数器，当时间窗口到达设定的时间后，计数器归零。如果在时间窗口内再次调用，则计数器再次增加。这种算法的优点是实现简单，但是存在临界问题。如果在一个时间窗口内的最后一次调用正好在时间窗口结束的瞬间，那么这个请求会被拒绝，因为计数器已经归零。为了解决这个问题，可以采用滑动窗口限流算法。该算法将时间窗口划分为多个小的时间段，每个时间段都有一个独立的计数器。当一个时间段结束时，该时间段的计数器归零，而其他时间段的计数器保持不变。这样就可以避免在时间窗口结束的瞬间出现请求被拒绝的情况。
用计数器实现限流有点简单粗暴，一般我们会限制一秒钟的能够通过的请求数，比如限流QPS为100，算法的实现思路就是从第一个请求进来开始计时，在接下去的1s内，每来一个请求，就把计数加1，如果累加的数字达到了100，那么后续的请求就会被全部拒绝。等到1s结束后，把计数恢复成0，重新开始计数。
具体的实现可以是这样的：对于每次服务调用，可以通过 AtomicLong#incrementAndGet()方法来给计数器加1并返回最新值，通过这个最新值和阈值进行比较。
这种实现方式，有一个弊端：如果我在单位时间1s内的前10ms，已经通过了100个请求，那后面的990ms，只能眼巴巴的把请求拒绝，我们把这种现象称为"突刺现象"。
（2）滑动窗口限流
本质上也是一种计数器，只是通过以时间为维度的可滑动窗口设计，来减少了临界值带来的并发超过阈值的问题。每次进行数据统计的时候，只需要统计这个窗口内每个时间刻度的访问量就可以了。Spring Cloud里面的熔断框架Hystrix ，以及Spring Cloud Alibaba里面的Sentinel都采用了滑动窗口来做数据统计。
（3）漏桶算法
漏桶算法主要是控制数据注入到网络的速率，平滑网络上的突发流量，是一种恒定速率的限流算法，不管请求量是多少，服务端的处理效率是恒定的。漏桶算法提供了一种机制，通过它，突发流量可以被整形以便为网络提供一个稳定的流量。基于 MQ 来实现的生产者消费者模型，其实算是一种漏桶限流算法。
漏桶可以看作是一个带有常量服务时间的单服务器队列，如果漏桶(包缓存)溢出，那么数据包会被丢弃。 在网络中，漏桶算法可以控制端口的流量输出速率，平滑网络上的突发流量，实现流量整形，从而为网络提供一个稳定的流量。
如图所示，把请求比作是水，水来了都先放进桶里，并以限定的速度出水，当水来得过猛而出水不够快时就会导致水直接溢出，即拒绝服务。
可以看出，漏桶算法可以很好地控制流量的访问速度，一旦超过该速度就拒绝服务。
（4）令牌桶算法
相对漏桶算法来说，它可以处理突发流量的问题。它的核心思想是，令牌桶以恒定速率去生成令牌保存到令牌桶里面，桶的大小是固定的，令牌桶满了以后就不再生成令牌。每个客户端请求进来的时候，必须要从令牌桶获得一个令牌才能访问，当桶里没有令牌可取时，则排队等待。在流量低峰的时候，令牌桶会出现堆积，因此当出现瞬时高峰的时候，有足够多的令牌可以获取，因此令牌桶能够允许瞬时流量的处理。
网关层面的限流、或者接口调用的限流，都可以使用令牌桶算法，像 Google 的 Guava，和 Redisson 的限流，都用到了令牌桶算法在我看来，限流的本质是实现系统保护，最终选择什么样的算法，一方面取决于统计的精准度，另一方面考虑限流维度和场景的需求。
从原理上看，令牌桶算法和漏桶算法是相反的，一个"进水"，一个是"漏水"。
