从分布式角度来看，限流可分为分布式限流（比如基于Sentinel或者Redis的集群限流）和单机限流。从算法实现角度来看，限流算法可分为漏桶算法、令牌桶算法和滑动时间窗口算法。下面主要分析这3种限流算法和分布式限流实现方案。
漏桶算法
把请求比作是水，水来了都先放进桶里，并以恒定速度出水（处理请求），当水流量过大会导致桶溢出，即拒绝服务。请求的最大处理速度也就是水从漏桶流出的速度。
基于漏桶（桶+恒定处理速率），可以起到对请求整流效果。漏桶算法可基于线程池来实现，线程池使用固定容量的阻塞队列+固定个数的处理线程来实现；最简单且最常见的漏桶思想的实现就是基于SynchronousQueue的线程池，其相当于一个空桶+固定处理线程 : )。
注意：原生的漏桶算法以恒定速度出水（处理请求），但是实际场景中请求的处理耗时可能不相等，为了实现恒定速率，一般都是限定同时处理请求的最大线程数。
令牌桶算法
令牌桶算法的原理是系统以恒定的速率产生令牌，然后把令牌放到令牌桶中，令牌桶有一个容量，当令牌桶满了的时候，再向其中放令牌，那么多余的令牌会被丢弃；当想要处理一个请求的时候，需要从令牌桶中取出一个令牌，如果此时令牌桶中没有令牌，那么则拒绝该请求。
很多场景中，需要允许某种程度的突发请求，请求的最大速度也就是所有桶大小。这时候漏桶算法就不合适了，令牌桶算法更为适合。
为什么令牌桶可以允许某种程度的突发请求呢？举个例子，桶的大小为500，漏桶出水速度为100/s，令牌桶的速度为100/s。采用漏桶算法处理速度是100/s，采用令牌桶如果桶是满的，处理速度就是500/s，甚至600/s。
令牌桶算法的一个实现方案是：起一个Timer线程以固定频率往桶中放令牌，桶满时令牌溢出，业务线程在获取令牌时直接从桶中获取即可。该方案容易理解，但是需要一个Timer线程，资源占用较重。
令牌桶算法还有一种实现方案不需要用Timer线程，这个经典实现就是Guava中的RateLimiter，大致原理如下
startTick记录RateLimiter初始化时的时间戳（单位ns），后续nowMicros(当前时间点)都是取(System.nanoTime()-startTick)/1000；nextFreeTicketMicros记录下次可获取令牌的开始时间点，在RateLimiter初始化和获取到令牌之后会进行更新；- 如果
nowMicros大于等于nextFreeTicketMicros，表示可以获取令牌；如果nowMicros大于nextFreeTicketMicros，会计算二者差值并除以放一个令牌的周期，然后赋值给storedPermits字段（表示当前桶中令牌数，注意不能超过桶容量）； - 然后
storedPermits减去当前需要令牌数，如果此时要获取令牌数大于storedPermits，那么会将nextFreeTicketMicros再往后推进(要获取令牌 - storedPermits) * 放一个令牌的周期的时间。
