坦白讲，实在上面的说法也不准确，由于做事降级、熔断本身也是限流的一种，由于它们实质上也是阻断了流量进来，但是本文希望大家可以把限流当做一个纯挚的名词来理解，看一下对要求做流控的几种算法及详细实现办法。
为什么要限流实在很好理解的一个问题，为什么要限流，自然就流量过大了呗，一个对外做事有很多场景都会流量增大：
业务用户量不断攀升各种匆匆销网络爬虫恶意刷单把稳这个"大"，1000QPS大吗？5000QPS大吗？10000QPS大么？没有答案，由于没有标准，因此，"大"一定是和正常流量比较的大。流量一大，做事器扛不住，扛不住就挂了，挂了没法供应对外做事导致业务直接熔断。怎么办，最直接的办法便是从源头把流量限定下来，例如做事器只有支撑1000QPS的处理能力，那就每秒放1000个要求，自然担保了做事器的稳定，这便是限流。
下面看一下常见的两种限流算法。
漏桶算法漏桶算法的事理比较大略，水（要求）前辈入到漏桶里，人为设置一个最大出水速率，漏桶以<=出水速率的速率出水，当水流入速度过大会直接溢出（谢绝做事）：
因此，这个算法的核心为：
存下要求匀速处理多于丢弃因此这是一种强行限定要求速率的办法，但是缺陷非常明显，紧张有两点：
无法面对突发的大流量----比如要求处理速率为1000，容量为5000，来了一波2000/s的要求持续10s，那么后5s的要求将全部直接被丢弃，做事器谢绝做事，但是实际上网络中突发一波大流量尤其是短韶光的大流量是非常正常的，超过容量就谢绝，非常大略粗暴无法有效利用网络资源----比如虽然做事器的处理能力是1000/s，但这不是绝对的，这个1000只是一个宏不雅观做事器处理能力的数字，实际上一共5秒，每秒要求量分别为1200、1300、1200、500、800，均匀下来qps也是1000/s，但是这个量对做事器来说完备是可以接管的，但是由于限定了速率是1000/s，因此前面的三秒，每秒只能处理掉1000个要求而一共打回了700个要求，白白摧残浪费蹂躏了做事器资源以是，常日来说利用漏桶算法来限流，实际场景下用得不多。
令牌桶算法
令牌桶算法是网络流量整形（Traffic Shaping）和限流（Rate Limiting）中最常利用的一种算法，它可用于掌握发送到网络上数据的数量并许可突发数据的发送。
从某种意义上来说，令牌桶算法是对漏桶算法的一种改进，紧张在于令牌桶算法能够在限定调用的均匀速率的同时还许可一定程度的突发调用，来看敕令牌桶算法的实现事理：
全体的过程是这样的：
系统以恒定的速率产生令牌，然后将令牌放入令牌桶中令牌桶有一个容量，当令牌桶满了的时候，再向个中放入的令牌就会被丢弃每次一个要求过来，须要从令牌桶中获取一个令牌，假设有令牌，那么供应做事；假设没有令牌，那么谢绝做事那么，我们再看一下，为什么令牌桶算法可以防止一定程度的突发流量呢？可以这么理解，假设我们想要的速率是1000QPS，那么往桶中放令牌的速率便是1000个/s，假设第1秒只有800个要求，那意味着第2秒可以容许1200个要求，这便是一定程度突发流量的意思，反之我们看漏桶算法，第一秒只有800个要求，那么全部放过，第二秒这1200个要求将会被打回200个。
把稳上面多次提到一定程度这四个字，这也是我认为令牌桶算法最须要把稳的一个点。假设还是1000QPS的速率，那么5秒钟放1000个令牌，第1秒钟800个要求过来，第2~4秒没有要求，那么按照令牌桶算法，第5秒钟可以接管4200个要求，但是实际上这已经远远超出了系统的承载能力，因此利用令牌桶算法特殊把稳设置桶中令牌的上限即可。
总而言之，作为对漏桶算法的改进，令牌桶算法在限流场景下被利用更加广泛。
RateLimiter利用上面说了令牌桶算法在限流场景下被利用更加广泛，接下来我们看一下代码示例，仿照一下每秒最多过五个要求：
public class RateLimiterTest { private static final SimpleDateFormat FORMATTER = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"); private static final int THREAD_COUNT = 25; @Test public void testRateLimiter1() { RateLimiter rateLimiter = RateLimiter.create(5); Thread[] ts = new Thread[THREAD_COUNT]; for (int i = 0; i < THREAD_COUNT; i++) { ts[i] = new Thread(new RateLimiterThread(rateLimiter), "RateLimiterThread-" + i); } for (int i = 0; i < THREAD_COUNT; i++) { ts[i].start(); } for (;;); } public class RateLimiterThread implements Runnable { private RateLimiter rateLimiter; public RateLimiterThread(RateLimiter rateLimiter) { this.rateLimiter = rateLimiter; } @Override public void run() { rateLimiter.acquire(1); System.out.println(Thread.currentThread().getName() + "获取到了令牌，韶光 = " + FORMATTER.format(new Date())); } } }
利用RateLimiter.create这个布局方法可以指定每秒向桶中放几个令牌，比方说上面的代码create(5)，那么每秒放置5个令牌，即200ms会向令牌桶中放置一个令牌。这边代码写了一条线程仿照实际场景，拿到令牌那么就能实行下面逻辑，看一下代码实行结果：
RateLimiterThread-0获取到了令牌，韶光 = 2019-08-25 20:58:53RateLimiterThread-23获取到了令牌，韶光 = 2019-08-25 20:58:54RateLimiterThread-21获取到了令牌，韶光 = 2019-08-25 20:58:54RateLimiterThread-19获取到了令牌，韶光 = 2019-08-25 20:58:54RateLimiterThread-17获取到了令牌，韶光 = 2019-08-25 20:58:54RateLimiterThread-13获取到了令牌，韶光 = 2019-08-25 20:58:54RateLimiterThread-9获取到了令牌，韶光 = 2019-08-25 20:58:55RateLimiterThread-15获取到了令牌，韶光 = 2019-08-25 20:58:55RateLimiterThread-5获取到了令牌，韶光 = 2019-08-25 20:58:55RateLimiterThread-1获取到了令牌，韶光 = 2019-08-25 20:58:55RateLimiterThread-11获取到了令牌，韶光 = 2019-08-25 20:58:55RateLimiterThread-7获取到了令牌，韶光 = 2019-08-25 20:58:56RateLimiterThread-3获取到了令牌，韶光 = 2019-08-25 20:58:56RateLimiterThread-4获取到了令牌，韶光 = 2019-08-25 20:58:56RateLimiterThread-8获取到了令牌，韶光 = 2019-08-25 20:58:56RateLimiterThread-12获取到了令牌，韶光 = 2019-08-25 20:58:56RateLimiterThread-16获取到了令牌，韶光 = 2019-08-25 20:58:57RateLimiterThread-20获取到了令牌，韶光 = 2019-08-25 20:58:57RateLimiterThread-24获取到了令牌，韶光 = 2019-08-25 20:58:57RateLimiterThread-2获取到了令牌，韶光 = 2019-08-25 20:58:57RateLimiterThread-6获取到了令牌，韶光 = 2019-08-25 20:58:57RateLimiterThread-10获取到了令牌，韶光 = 2019-08-25 20:58:58RateLimiterThread-14获取到了令牌，韶光 = 2019-08-25 20:58:58RateLimiterThread-18获取到了令牌，韶光 = 2019-08-25 20:58:58RateLimiterThread-22获取到了令牌，韶光 = 2019-08-25 20:58:58
看到，非常标准，在每次花费一个令牌的情形下，RateLimiter可以担保每一秒内最多只有5个线程获取到令牌，利用这种办法可以很好的做单机对要求的QPS数掌握。
至于为什么2019-08-25 20:58:53这个韶光点只有1条线程获取到了令牌而不是有5条线程获取到令牌，由于RateLimiter是按照秒计数的，可能第一个线程是2019-08-25 20:58:53.999秒来的，算在2019-08-25 20:58:53这一秒内；下一个线程2019-08-25 20:58:54.001秒来，自然就算到2019-08-25 20:58:54这一秒去了。
上面的写法是RateLimiter最常用的写法，把稳：
acquire是壅塞的且会一贯等待到获取令牌为止，它有一个返回值为double型，意思是从壅塞开始到获取到令牌的等待韶光，单位为秒tryAcquire是其余一个方法，它可以指定超时时间，返回值为boolean型，即假设线程等待了指定时间后仍旧没有获取到令牌，那么就会返回给客户端false，客户端根据自身情形是打回给前台缺点还是定时重试RateLimiter预消费处理要求，每次来一个要求就acquire一把是RateLimiter最常见的用法，但是我们看acquire还有个acquire(int permits)的重载方法，即许可每次获取多个令牌数。这也是有可能的，要求数是一个大维度每次扣减1，有可能做事器按照字节数来进行限流，例如每秒最多处理10000字节的数据，那每次扣减的就不止1了。
接着我们再看一段代码示例：
@Testpublic void testRateLimiter2() { RateLimiter rateLimiter = RateLimiter.create(1); System.out.println("获取1个令牌开始，韶光为" + FORMATTER.format(new Date())); double cost = rateLimiter.acquire(1); System.out.println("获取1个令牌结束，韶光为" + FORMATTER.format(new Date()) + ", 耗时" + cost + "ms"); System.out.println("获取5个令牌开始，韶光为" + FORMATTER.format(new Date())); cost = rateLimiter.acquire(5); System.out.println("获取5个令牌结束，韶光为" + FORMATTER.format(new Date()) + ", 耗时" + cost + "ms"); System.out.println("获取3个令牌开始，韶光为" + FORMATTER.format(new Date())); cost = rateLimiter.acquire(3); System.out.println("获取3个令牌结束，韶光为" + FORMATTER.format(new Date()) + ", 耗时" + cost + "ms");}
代码运行结果为：
获取1个令牌开始，韶光为2019-08-25 21:21:09.973获取1个令牌结束，韶光为2019-08-25 21:21:09.976, 耗时0.0ms获取5个令牌开始，韶光为2019-08-25 21:21:09.976获取5个令牌结束，韶光为2019-08-25 21:21:10.974, 耗时0.997237ms获取3个令牌开始，韶光为2019-08-25 21:21:10.976获取3个令牌结束，韶光为2019-08-25 21:21:15.974, 耗时4.996529ms
看到这便是标题所说的预消费能力，也是RateLimiter中许可一定程度突发流量的实现办法。第二次须要获取5个令牌，指定的是每秒放1个令牌到桶中，我们创造实际上并没有等5秒钟等桶中积累了5个令牌才能让第二次acquire成功，而是直接等了1秒钟就成功了。我们可以捋一捋这个逻辑：
第一次要求过来须要获取1个令牌，直接拿到RateLimiter在1秒钟后放一个令牌，第一次要求预支的1个令牌还上了1秒钟之后第二次要求过来须要得到5个令牌，直接拿到RateLimiter在花了5秒钟放了5个令牌，还上了第二次要求预支的5个令牌第三个要求在5秒钟之后拿到3个令牌也便是说，前面的要求如果流量大于每秒放置令牌的数量，那么许可处理，但是带来的结果便是后面的要求延后处理，从而在整体上达到一个平衡整体处理速率的效果。
突发流量的处理，在令牌桶算法中有两种办法，一种是有足够的令牌才能消费，一种是先消费后还令牌。后者就像我们0首付买车似的，30万的车很少有等攒到30万才全款买的，先签了干系条约把车子给你，然后贷款逐步还，这样就爽了。RateLimiter也是同样的道理，先让要求得到处理，再逐步还上预支的令牌，客户端同样也爽了，否则我假设预支60个令牌，1分钟之后才能处理我的要求，不合理也不人性化。
RateLimiter的限定
特殊把稳RateLimiter是单机的，也便是说它无法跨JVM利用，设置的1000QPS，那也在单机中担保均匀1000QPS的流量。
假设集群中支配了10台做事器，想要担保集群1000QPS的接口调用量，那么RateLimiter就不适用了，集群流控最常见的方法是利用强大的Redis：
一种是固定窗口的计数，例如当前是2019/8/26 20:05:00，就往这个"2019/8/26 20:05:00"这个key进行incr，当前是2019/8/26 20:05:01，就往"2019/8/26 20:05:01"这个key进行incr，incr后的结果只要大于我们设定的值，那么就打回去，小于就相称于获取到了实行权限一种是结合lua脚本，实现分布式的令牌桶算法，网上实现还是比较多的总得来说，集群限流的实现也比较大略。
总结
本文紧张写了常见的两种限流算法漏桶算法与令牌桶算法，并且演示了Guava中RateLimiter的实现，相信看到这里的朋友一定都懂了，恭喜你们！
令牌桶算法是最常用的限流算法，它最大的特点便是容许一定程度的突发流量。
漏桶算法同样也有自己的运用之处，例如Nginx的限流模块便是基于漏桶算法的，它最大的特点便是强行限定流量按照指定的比例下发，适宜那种对流量有绝对哀求的场景，便是流量可以容许在我指定的值之下，可以被多次打回，但是无论如何决不能超过指定的。
虽然令牌桶算法相对更好，但是还是我常常说的，利用哪种完备就看大家各自的场景，适宜的才是最好的。
