漏桶算法与令牌桶算法在表面看起来类似，很容易将两者混淆。但事实上，这两者具有截然不同的特性，且为不同的目的而使用。漏桶算法与令牌桶算法的区别在于：漏桶算法能够强行限制数据的传输速率。令牌桶算法能够在限制数据的平均传输速率的同时还允许某种程度的突发传输。需要说明的是：在某些情况下，漏桶算法不能够有效地使用网络资源。因为漏桶的漏出速率是固定的，所以即使网络中没有发生拥塞，漏桶算法也不能使某一个单独的数据流达到端口速率。因此，漏桶算法对于存在突发特性的流量来说缺乏效率。而令牌桶算法则能够满足这些具有突发特性的流量。通常，漏桶算法与令牌桶算法结合起来为网络流量提供更高效的控制
漏桶限流算法的原理
以固定速率从桶中流出水滴，以任意速率往桶中放入水滴，桶容量大小是不会发生改变的。
流入：以任意速率往桶中放入水滴。
流出：以固定速率从桶中流出水滴。
水滴：是唯一不重复的标识。
因为桶中的容量是固定的，如果流入水滴的速率>流出的水滴速率，桶中的水滴可能会溢出。那么溢出的水滴请求都是拒绝访问的，或者直接调用服务降级方法。前提是同一时刻
令牌桶算法(Token)
令牌桶分为2个动作，动作1(固定速率往桶中存入令牌)、动作2(客户端如果想访问请求，先从桶中获取token)。guava 提供的RateLimiter类来进行限流处理。
1.传统的方式整合RateLimiter 有很大的缺点：代码重复量特别大，而且本身不支持注解方式。
2.如果限流代码可以放在网关中，相当于针对所有的服务接口都实现限流(可以使用排除法进行排除不进行限流的方法)，维护性不是很强。
3.正常的互联网公司项目，不是所有的服务接口都需要实现限流方法的，一般只真针对于大流量接口。比如：秒杀抢购、12306抢票等。
4.可以手动封装一个RateLimiter类 注解来解决这个方法
以规定的速率往令牌桶中放入 token，用户请求必须获取到令牌桶中的 token才可以访问我们的业务逻辑方法，如果没有从令牌桶中获取到 token ，拒绝访问。
在高并发情况下，如果我们的请求过多 超出了令牌桶生成令牌的速度，这时候请求就会被驳回，提示请稍后重试！
优势：能够控制请求的速率。
限流的目的：为了保护服务，避免服务宕机
总结
常用的限流算法有两种：漏桶算法和令牌桶算法。
漏桶算法思路很简单，水（请求）先进入到漏桶里，漏桶以一定的速度出水，当水流入速度过大会直接溢出，可以看出漏桶算法能强行限制数据的传输速率
对于很多应用场景来说，除了要求能够限制数据的平均传输速率外，还要求允许某种程度的突发传输。这时候漏桶算法可能就不合适了，令牌桶算法更为适合。如图2所示，令牌桶算法的原理是系统会以一个恒定的速度往桶里放入令牌，而如果请求需要被处理，则需要先从桶里获取一个令牌，当桶里没有令牌可取时，则拒绝服务
并不能说明令牌桶一定比漏洞好，她们使用场景不一样。令牌桶可以用来保护自己，主要用来对调用者频率进行限流，为的是让自己不被打垮。所以如果自己本身有处理能力的时候，如果流量突发（实际消费能力强于配置的流量限制），那么实际处理速率可以超过配置的限制。而漏桶算法，这是用来保护他人，也就是保护他所调用的系统。主要场景是，当调用的第三方系统本身没有保护机制，或者有流量限制的时候，我们的调用速度不能超过他的限制，由于我们不能更改第三方系统，所以只有在主调方控制。这个时候，即使流量突发，也必须舍弃。因为消费能力是第三方决定的。
总结起来：如果要让自己的系统不被打垮，用令牌桶。如果保证被别人的系统不被打垮，用漏桶算法