令牌桶（令牌桶和漏桶的区别）

今天给各位分享令牌桶的知识，其中也会对令牌桶和漏桶的区别进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、令牌桶（Token Bucket）
• 2、限流和常见的三种算法
• 3、RateLimiter令牌桶算法浅析
• 4、限流算法之漏桶、令牌桶的区别
• 5、分布式解决方案之：限流
• 6、令牌桶技术属于链路层吗

令牌桶（Token Bucket）

想象有一个木桶，系统按照固定速率，例如10ms每次，往桶里加入Token，如果桶已经满了就不再添加。新请求来临时，会各自拿走一个Token，如果没有Token 就拒绝服务。这里如果一段时间没有请求时，桶内就会积累一些token，下次一旦有突发流量，只要token足够，也能一次处理。

总结下令牌桶算法的特点，令牌桶即可以控制进入系统的请求请求量，同时允许突发流量。

在秒杀活动中，用户的请求速率是不固定的，这里我们假定为10r/s，令牌按照5个每秒的速率放入令牌桶，桶中最多存放20个令牌，那系统就只会允许持续的每秒处理5 个请求，或者每隔4 秒，等桶中20 个令牌攒满后，一次处理20个请求的突发情况，保证系统稳定性。

go简易版实现

限流和常见的三种算法

限流的三种算法

限流要解决的问题

典型限流的应用场景：

如何限流？

一般网关都有这种功能。 gateway、nginx、zuul等

限流：一定时间内，只允许N次请求。

从计算机友好的角度出发，是希望能在单位时间内均摊掉请求，使用漏斗算法可以达到这种效果。

但是漏斗算法有个弊端，就是先快后慢的这种请求，那么峰值的请求也只能排队等待被消费。实际上计算机是具备一定的高并发处理能力的，只要不是一直处于高并发下即可。所以 计数器限流和 漏洞限流折中的算法，令牌限流成为现在最主流的算法。

（Redis 结合expire方案可以实现)

第一次请求开始计时，例如1s以内，达到100次请求就拒绝访问了，直到1s过后，重新开始计数。

优点：

缺点：短暂的峰值过高对服务器不友好。服务器希望能把请求尽量的均摊开来，这样可以充分利用计算机资源。

消费的速度是恒定的，对于服务器而言是最友好的。

在算法实现方面，可以准备一个队列，用来保存请求，另外通过一个线程池（ScheduledExecutorService）来定期从队列中获取请求并执行，可以一次性获取多个并发执行。

参数：消费速度、桶容量（超过就抛弃，可以避免内存过大，有过多的等待的任务)

优点：

缺点：

令牌桶算法是比较常见的限流算法之一，大概描述如下：

1）所有的请求在处理之前都需要拿到一个可用的令牌才会被处理；

2）根据限流大小，设置按照一定的速率往桶里添加令牌；

3）桶设置最大的放置令牌限制，当桶满时、新添加的令牌就被丢弃活着拒绝；

4）请求达到后首先要获取令牌桶中的令牌，拿着令牌才可以进行其他的业务逻辑，处理完业务逻辑之后，将令牌直接删除；

5）令牌桶有最低限额，当桶中的令牌达到最低限额的时候，请求处理完之后将不会删除令牌，以此保证足够的限流；

这种算法，既可以保证系统由一定的高并发能力，比如当前令牌桶容量是100，一开始直接消费掉100个请求。有保证服务器不会因为短暂的爆发，而导致server端空闲，因为令牌桶还会持续的生产令牌。

既有一定的并发能力，又不至于完全失去控制，可控的兼具并发力和流量控制的限流算法.是计数器算法（一定的并发处理能力）和漏洞限流（高峰过后仍然会持续的产生令牌）的折中算法。

RateLimiter令牌桶算法浅析

百度百科中的定义：

令牌桶算法是网络流量（Traffic Shaping）整形（Traffic Shaping）和速率限制（Rate Limiting）中最常使用的一种算法。典型情况下，令牌桶算法用来控制发送到网络上的数据的数目，并允许突发数据的发送。

大小固定的令牌桶可自行以恒定的速率源源不断地产生令牌。如果令牌不被消耗，或者被消耗的速度小于产生的速度，令牌就会不断地增多，直到把桶填满。后面再产生的令牌就会从桶中溢出。最后桶中可以保存的最大令牌数永远不会超过桶的大小。

传送到令牌桶的数据包需要消耗令牌。不同大小的数据包，消耗的令牌数量不一样。令牌桶这种控制机制基于令牌桶中是否存在令牌来指示什么时候可以发送流量。令牌桶中的每一个令牌都代表一个字节。如果令牌桶中存在令牌，则允许发送流量；而如果令牌桶中不存在令牌，则不允许发送流量。因此，如果突发门限被合理地配置并且令牌桶中有足够的令牌，那么流量就可以以峰值速率发送。

令牌桶算法的基本过程：

假如用户配置的平均发送速率为r，则每隔1/r秒一个令牌被加入到桶中；桶最多可以存发b个令牌。如果令牌到达时令牌桶已满，则这个令牌会被丢弃；

当一个n个字节的数据包到达时，就从令牌桶中删除n个令牌，并且数据包被发送到网络；

如果令牌桶中少于n个令牌，则不会删除令牌，并且认为这个数据包在流量限制之外；

算法允许最长b个字节的突发，数据包的速率被限制成常量r。对于在流量限制外的数据包可以以不同的方式处理：

1）被丢弃；

2）放在队列中当令牌桶中累积了足够多的令牌时再传输；

3）继续发送，但需要做特殊标记，网络过载时将这些特殊标记的包丢弃。

令牌桶算法与漏桶算法（Leaky Bucket）的主要区别：

1）漏桶算法能够强行限制数据的传输速率，而令牌桶算法在能够限制数据的平均传输速率外，还允许某种程度的突发传输。

2）令牌桶算法中，只要令牌桶中存在令牌，就允许突发地传输数据直到达到用户配置的上限，它适合于具有突发特性的流量。

RateLimiter是Guava中开源的一个令牌桶算法工具类，可以轻松实现限流工作。

RateLimiter有两个实现类：SmoothBursty和SmoothWarmingUp;

两者区别：

1）都是令牌桶算法的变种实现

2）SmoothBursty加令牌的速度是恒定的，SmoothWarmingUp会有个预热期，在预热期内加令牌的速度是慢慢增加的，直到达到固定速度为止。其适用场景是，对于有的系统而言刚启动时能承受的QPS较小，需要预热一段时间后才能达到最佳状态。

测试示例：

示例1：创建一个令牌桶，每秒生成一个令牌，申请失败立即返回。使用CountdownLatch计数器模拟多线程并发，调用await()方法阻塞当前线程，当计数完成后，唤醒所有线程并发执行。

示例2：创建一个令牌桶，每秒生成0.1个令牌，即每10s才会有一个令牌，超时时间设置成20s，20s内获取不到令牌返回失败，20s内可以生成2个令牌，加上创建时桶里会有一个令牌，超时前最终会有3条线程拿到令牌，并且每个令牌获取时间相隔10s。使用CountdownLatch计数器模拟多线程并发：调用await()方法阻塞当前线程，当计数完成后，唤醒所有线程并发执行。

参考文档：

限流算法之漏桶、令牌桶的区别

漏桶算法(Leaky Bucket)是网络世界中流量整形（Traffic Shaping）或速率限制（Rate Limiting）时经常使用的一种算法，它的主要目的是控制数据注入到网络的速率，平滑网络上的突发流量。漏桶算法提供了一种机制，通过它，突发流量可以被整形以便为网络提供一个稳定的流量。

漏桶可以看作是一个带有常量服务时间的单服务器队列，如果漏桶（包缓存）溢出，那么数据包会被丢弃。 在网络中，漏桶算法可以控制端口的流量输出速率，平滑网络上的突发流量，实现流量整形，从而为网络提供一个稳定的流量。

如图所示，把请求比作是水，水来了都先放进桶里，并以限定的速度出水，当水来得过猛而出水不够快时就会导致水直接溢出，即拒绝服务。

可以看出，漏桶算法可以很好的控制流量的访问速度，一旦超过该速度就拒绝服务。

令牌桶算法是网络流量整形（Traffic Shaping）和速率限制（Rate Limiting）中最常使用的一种算法。典型情况下，令牌桶算法用来控制发送到网络上的数据的数目，并允许突发数据的发送。

令牌桶算法的原理是系统会以一个恒定的速度往桶里放入令牌，而如果请求需要被处理，则需要先从桶里获取一个令牌，当桶里没有令牌可取时，则拒绝服务。从原理上看，令牌桶算法和漏桶算法是相反的，一个“进水”，一个是“漏水”。

Google的Guava包中的RateLimiter类就是令牌桶算法的解决方案。

漏桶算法与令牌桶算法在表面看起来类似，很容易将两者混淆。但事实上，这两者具有截然不同的特性，且为不同的目的而使用。

漏桶算法与令牌桶算法的区别在于，漏桶算法能够强行限制数据的传输速率，令牌桶算法能够在限制数据的平均传输速率的同时还允许某种程度的突发传输。

需要注意的是，在某些情况下，漏桶算法不能够有效地使用网络资源，因为漏桶的漏出速率是固定的，所以即使网络中没有发生拥塞，漏桶算法也不能使某一个单独的数据流达到端口速率。因此，漏桶算法对于存在突发特性的流量来说缺乏效率。而令牌桶算法则能够满足这些具有突发特性的流量。通常，漏桶算法与令牌桶算法结合起来为网络流量提供更高效的控制。

查看原文可以戳这里

限流技术早期被应用于控制网络接口收发通信数据的速率，在互联网领域，也借鉴了这个概念，用于为服务控制请求的速率。

这段话怎么理解呢，比如说存在两个系统A、B，公用一个网络，网络带宽为2M, A、B各分得1M，此时通过漏桶算法控制两个系统使用网络的速率，A、B系统使用网络的速率固定最大值为1M,无论A、B系统接受多少流量，但流出的速率都限制在最大1M,当网络中没有发生拥塞，也就是可能出现B系统可能空闲没有使用网络，对应分给B系统的1M带宽是空闲的，而A系统这一时刻接收了5M的流量，由于漏桶限流的存在，A只能使用1M带宽，我们的带宽有2M,此刻我们只能使用1M,也就是达不到带宽的最大速率，另外1M带宽是浪费的，因此不能充分利用，缺乏效率；当然从另一方面来讲也带来了好处，就是隔离性，A系统无论收到多大的流量冲击，对于B系统的无感的，不会因为流量冲击A,而B受到影响.

这段又该怎么理解呢，比如我们的目标现在是每秒钟处理10个请求，使用漏桶法，我们设置桶的大小为10，流出的速率为0.1s流出一个请求，我们可以达成我们的目标；而使用令牌桶的话，我们会设置每1s向桶中放入10个令牌，请求如果是平稳的，每0.1s过来一个请求，来十个，同样能达到我们的目标，这里所说的某种程度的突发传输是指，比如在一秒内前0.5请求是平稳的，每0.1s来一个，但在0.6s的时候突发请求同时来个5个请求，此时令牌算法是可以承受这个突发流量的，并且让5个请求成功立刻同时通过，完成了所谓的某种程度的突发传输，而漏桶算法，也可以应对这种突发流量，但不同的是没有让5个请求同时立刻通过，而是缓冲在桶中，然后仍然以固定速率每0.1s通过一个。

这两种算法，都可以实现流速的控制，1s处理10个请求，多于10个的请求都会被拒绝，但由于漏桶算法流出速率是一定的，所以请求可能会被缓冲在桶中，不能马上得到处理，从而徒增了等待时间，而对于令牌桶算法，没有这种等待时间，有令牌则通过，无令牌则抛弃。

分布式解决方案之：限流

限流在日常生活中限流很常见，例如去有些景区玩，每天售卖的门票数是有限的，例如 2000 张，即每天最多只有 2000 个人能进去游玩。那在我们工程上限流是什么呢？限制的是 「流」，在不同场景下「流」的定义不同，可以是 每秒请求数、每秒事务处理数、网络流量 等等。通常意义我们说的限流指代的是限制到达系统的并发请求数，使得系统能够正常的处理部分用户的请求，来保证系统的稳定性。

日常的业务上有类似秒杀活动、双十一大促或者突发新闻等场景，用户的流量突增，后端服务的处理能力是有限的，如果不能处理好突发流量，后端服务很容易就被打垮。另外像爬虫之类的不正常流量，我们对外暴露的服务都要以最大恶意为前提去防备调用者。我们不清楚调用者会如何调用我们的服务，假设某个调用者开几十个线程一天二十四小时疯狂调用你的服务，如果不做啥处理咱服务基本也玩完了，更胜者还有ddos攻击。

对于很多第三方开放平台来说，不仅仅要防备不正常流量，还要保证资源的公平利用，一些接口资源不可能一直都被一个客户端占着，也需要保证其他客户端能正常调用。

计数器限流也就是最简单的限流算法就是计数限流了。例如系统能同时处理 100 个请求，保存一个计数器，处理了一个请求，计数器就加一，一个请求处理完毕之后计数器减一。每次请求来的时候看看计数器的值，如果超过阈值就拒绝。计数器的值要是存内存中就算单机限流算法，如果放在第三方存储里（例如Redis中）集群机器访问就算分布式限流算法。

一般的限流都是为了限制在指定时间间隔内的访问量，因此还有个算法叫固定窗口。

它相比于计数限流主要是多了个时间窗口的概念，计数器每过一个时间窗口就重置。规则如下：

这种方式也会面临一些问题，例如固定窗口临界问题：假设系统每秒允许 100 个请求，假设第一个时间窗口是 0-1s，在第 0.55s 处一下次涌入 100 个请求，过了 1 秒的时间窗口后计数清零，此时在 1.05 s 的时候又一下次涌入100个请求。虽然窗口内的计数没超过阈值，但是全局来看在 0.55s-1.05s 这 0.1 秒内涌入了 200 个请求，这其实对于阈值是 100/s 的系统来说是无法接受的。

为了解决这个问题，业界又提出另外一种限流算法，即滑动窗口限流。

滑动窗口限流解决固定窗口临界值的问题，可以保证在任意时间窗口内都不会超过阈值。相对于固定窗口，滑动窗口除了需要引入计数器之外还需要记录时间窗口内每个请求到达的时间点，因此对内存的占用会比较多。

规则如下，假设时间窗口为 1 秒：

但是滑动窗口和固定窗口都无法解决短时间之内集中流量的冲击问题。 我们所想的限流场景是： 每秒限制 100 个请求。希望请求每 10ms 来一个，这样我们的流量处理就很平滑，但是真实场景很难控制请求的频率，因为可能就算我们设置了1s内只能有100个请求，也可能存在 5ms 内就打满了阈值的情况。当然对于这种情况还是有变型处理的，例如设置多条限流规则。不仅限制每秒 100 个请求，再设置每 10ms 不超过 2 个，不过带来的就是比较差的用户体验。

而漏桶算法，可以解决时间窗口类的痛点，使得流量更加平滑。

如下图所示，水滴持续滴入漏桶中，底部定速流出。如果水滴滴入的速率大于流出的速率，当存水超过桶的大小的时候就会溢出。

规则如下：

水滴对应的就是请求。

与线程池实现的方式方式如出一辙。

面对突发请求，服务的处理速度和平时是一样的，这并非我们实际想要的。我们希望的是在突发流量时，在保证系统平稳的同时，也要尽可能提升用户体验，也就是能更快地处理并响应请求，而不是和正常流量一样循规蹈矩地处理。

而令牌桶在应对突击流量的时候，可以更加的“激进”。

令牌桶其实和漏桶的原理类似，只不过漏桶是定速地流出，而令牌桶是定速地往桶里塞入令牌，然后请求只有拿到了令牌才能通过，之后再被服务器处理。

当然令牌桶的大小也是有限制的，假设桶里的令牌满了之后，定速生成的令牌会丢弃。

规则：

令牌桶的原理与JUC的Semaphore 信号量很相似，信号量可控制某个资源被同时访问的个数，其实和拿令牌思想一样，不同的是一个是拿信号量，一个是拿令牌。信号量用完了返还，而令牌用了不归还，因为令牌会定时再填充。

对比漏桶算法可以看出 令牌桶更适合应对突发流量 ，假如桶内有 100 个令牌，那么这100个令牌可以马上被取走，而不像漏桶那样匀速的消费。不过上面批量获取令牌也会致使一些新的问题出现，比如导致一定范围内的限流误差，举个例子你取了 10 个此时不用，等下一秒再用，那同一时刻集群机器总处理量可能会超过阈值，所以现实中使用时，可能不会去考虑redis频繁读取问题，转而直接采用一次获取一个令牌的方式，具体采用哪种策略还是要根据真实场景而定。

1、计数器 VS 固定窗口 VS 滑动窗口

2、漏桶算法 VS 令牌桶算法

总的来说

单机限流和分布式限流本质上的区别在于 “阈值” 存放的位置，单机限流就是“阀值”存放在单机部署的服务/内存中，但我们的服务往往是集群部署的，因此需要多台机器协同提供限流功能。像上述的计数器或者时间窗口的算法，可以将计数器存放至 Redis 等分布式 K-V 存储中。又如滑动窗口的每个请求的时间记录可以利用 Redis 的 zset 存储，利用 ZREMRANGEBYSCORE 删除时间窗口之外的数据，再用 ZCARD 计数，

可以看到，每个限流都有个阈值，这个阈值如何定是个难点。定大了服务器可能顶不住，定小了就“误杀”了，没有资源利用最大化，对用户体验不好。一般的做法是限流上线之后先预估个大概的阈值，然后不执行真正的限流操作，而是采取日志记录方式，对日志进行分析查看限流的效果，然后调整阈值，推算出集群总的处理能力，和每台机子的处理能力(方便扩缩容)。然后将线上的流量进行重放，测试真正的限流效果，最终阈值确定，然后上线。

其实真实的业务场景很复杂，需要限流的条件和资源很多，每个资源限流要求还不一样。

一般而言，我们不需要自己实现限流算法来达到限流的目的，不管是接入层限流还是细粒度的接口限流，都有现成的轮子使用，其实现也是用了上述我们所说的限流算法。

具体的使用还是很简单的，有兴趣的同学可以自行搜索，对内部实现感兴趣的同学可以下个源码看看，学习下生产级别的限流是如何实现的。

限流具体应用到工程还是有很多点需要考虑的，并且限流只是保证系统稳定性中的一个环节，还需要配合降级、熔断等相关内容。

令牌桶技术属于链路层吗

令牌桶技术不属于链路层，而是属于传输层。它是一种流量控制算法，用于限制发送端发送数据的速率，以避免网络中出现过多的数据包而导致的丢包问题。

令牌桶的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于令牌桶和漏桶的区别、令牌桶的信息别忘了在本站进行查找喔。