spring Boot 接口如何限流？限流的几种方式
场景
在一个高并发系统中对流量的把控是非常重要的，当巨大的流量直接请求到我们的服务器上没多久就可能造成接口不可用，不处理的话甚至会造成整个应用不可用。
常用算法有：计数算法、漏桶算法、令牌桶算法，最常用的算法是后两种。
1.计数算法
计数器法是限流算法里最简单也是最容易实现的一种算法。例如系统能同时处理10000个请求，将该值保存一个计数器，处理一个请求，计数器加一，处理完一个计数器减一。
每次请求时先判断下计数器的值，如果超过阈值则拒绝。
优点：简单粗暴，单机在Java中可用Atomic等原子类，分布式就用Redis incr。
缺点：假设系统设置的阈值是10000，当前计数器为0，可能在某一秒内10000个请求同时访问进来，突发的流量可能瞬间击垮服务。对程序来说缓慢增加处理和瞬时并发是不一样的。
2.漏桶算法
漏桶算法相对前面的计数算法更加柔性，它的原理也很简单，可以认为就是注水漏水的过程。
漏桶接受以任意速率流入的水，并且以固定速率将水流出。当水超过桶的容量时，会被溢出，也就相当于被丢弃。漏桶算法保证了整体的速率。
- 流入漏桶的水滴，看作是访问系统的请求，这个流入速率是不确定的。
- 桶的容量表示系统当前所能处理的请求数。
- 如果桶的容量满了，就达到了限流的阈值，此时再有水滴将会被丢弃（拒绝请求）。
- 流出的水滴，是匀速恒定的，按照服务设定的固定速率处理请求。
漏桶算法原理与消息队列思想有些类似，都是进行削峰填谷，经过漏桶后请求就能匀速平滑的流出，但实际上它的优点也是缺点。
面对突发请求，服务的处理速度和平常一样，这其实不是我们想要的。我们更想要的是面对突发流量时，在系统平稳运行的同时又能更快的处理请求，而不是一直按照统一的速率来处理。
相对利弊也是分使用场景的，漏桶算法，主要用来保护别人的接口。
令牌桶算法
令牌桶算法是对漏斗算法的一种改进，除了能够起到限流的作用外，还允许一定程度的流量突发。
令牌桶算法主要时匀速的增加可用令牌，令牌数因为桶的限制有数量上线。
请求拿到令牌，相当于拿到了授权，即可进行相应的业务操作。
与漏桶算法相比，有可能导致短时间内的请求数上升（因为拿到令牌后，就可以访问接口，存在一瞬间将所有令牌拿走的情况），但不会有计数算法那样高的峰值（因为令牌数量是匀速增加的）。所以在应对突发流量的时候令牌桶表现的更佳。
一般自己调用自己的接口，接口会有一定的伸缩性，令牌桶算法，主要用来保护自己的服务器接口。
结论
- 想要达到限流的目的，又不会掐断流量，使得流量更加平滑？可以考虑漏桶算法！需要注意的是，漏桶算法通常配置一个FIFO的队列使用以达到允许限流的作用。由于速率固定，即使在某个时刻下游处理能力过剩，也不能得到很好的利用，这是漏桶算法的一个短板。
- 限流和瞬时流量其实并不矛盾，在大多数场景中，短时间突发流量系统是完全可以接受的。令牌桶算法就是不二之选了，令牌桶以固定的速率v产生令牌放入一个固定容量为n的桶中，当请求到达时尝试从桶中获取令牌。当桶满时，允许最大瞬时流量为n；当桶中没有剩余流量时则限流速率最低，为令牌生成的速率v。
