限流算法思想
固定窗口计数器算法
其原理是将时间划分为固定大小的窗口，在每个窗口内限制请求的数量或速率，即固定窗口计数器算法规定了系统单位时间处理的请求数量
优点：实现简单，易于理解
缺点：1.限流不够平滑 2.无法保证限流速率，因而无法应对突然激增的流量。（例如大量请求集中在某1S）
滑动串口计数器算法
滑动窗口计数器算法 算的上是固定窗口计数器算法的升级版，限流的颗粒度更小。它把时间以一定比例分片 。例如我们的接口限流每分钟处理 60 个请求，我们可以把 1 分钟分为 60 个窗口。每隔 1 秒移动一次，每个窗口一秒只能处理不大于 60(请求数)/60（窗口数） 的请求， 如果当前窗口的请求计数总和超过了限制的数量的话就不再处理其他请求。
很显然， 当滑动窗口的格子划分的越多，滑动窗口的滚动就越平滑，限流的统计就会越精确。
优点：1.相比固定窗口，可以应对突然激增的流量 2.相比固定窗口，颗粒度更小，可以实现限流更精确的控制
缺点：1.依然存在不够平滑的问题 2.实现和理解更复杂
漏桶算法
我们往桶中以任意速率流入水，以一定速率流出水。当水超过桶流量则丢弃，因为桶容量是不变的，保证了整体的速率。具体实现可以准备一个队列用来保存请求，然后我们定期从队列中拿请求来执行就好了（和消息队列削峰/限流的思想是一样的）
优点：1.实现简单易理解 2.可以控制限流速率，避免网络拥塞和系统过载
缺点：1.无法应对突然激增的流量，对系统资源利用不友好 2.如果发请求（桶流入的速率）一直大于桶流出，会丢失大量请求，导致服务质量下降
令牌桶算法
桶中装的是令牌，以一定的速率生成令牌，桶满了，就不能添加令牌了，到来的请求需要在桶中取令牌，取不到令牌的任务会被丢弃。
优点：1.可以限制平均速率和应对突然激增的流量 2.可以动态调整生成令牌的速率
缺点：1.令牌生产速率不合理，可能会有大量请求被丢弃，系统过载 2.实现理解也复杂一些
- 实现方案：Guava RateLimiter限流
- Guava RateLimiter是一个谷歌提供的限流，其基于令牌桶算法，比较适用于单实例的系统。