分布式限流篇

具体内容请看作者：https://mp.weixin.qq.com/s/dfI9h8bdYgZ60UeByphhYQ

在系统设计中，限流是保障系统高可用的一种常规手段，并且还有熔断，服务降级…

对于系统接入大量的业务线，导致流量非常大，一些系统承受不住被搞挂。

Martin有几种方法来进行系统优化。

1、限流：对应用入口流量做控制，瞬时流量向后迁移，对下游请求流量做自适应限流，根据接口响应时间动态调整流量。

2、延迟排队：如果请求量大，按业务线优先级排队，优先保障线上渠道实时的请求。

3、路由：这个是因为业务的特殊性，所有的请求都依赖于下游第三方的服务，可以将多家下游服务供应商做个动态路由表，将请求优先路由给接口成功率高，耗时低的服务供应商。

4、备份：这基本是所有分布式组件都会做的，能做多机的不做单机的，比如说Redis做三主三备（集群）、MySQL分库分表、MQ与Redis互为备份等等。

5、降级：这个是最后的迫不得已的措施，如果遇到全线崩溃，使用降级手段保障系统核心功能可用，或让模块达到最小可用。

6、日志：完整的监控和链路日志，日志的功能很多，一方面是方面排查问题，另一方面可用来做任务重试、任务回滚、数据恢复、状态持久化等。

那怎么去实现限流呢？

一般是单机的话，可以通过Semphore限制统一时间请求接口的量，也可以用Google Guava包提供的限流包。

但是如果是分布式环境的话，也可以使用Redis实现，当然也有阿里的Sentinal或Spring Cloud Gateway都可以实现限流。

现在我们可以用单机模式来测试一下：

 1 private static Semphore semphore = new Semphore(3);
 2 
 3 private static String[]  userName = {"Krics","Martin","Mark"};
 4 //设置一个随机数
 5 private static Random random = new Random();
 6 
 7 //厕所类
 8 public static class Tailet{
 9 
10       public void enter(User user){
11            try{
12             semphore.acquire();
13                if(Thread.interrupated()){
14                      return;
15                      }
16                System.out.println("时间："+ DateAndTimeUtil.getFormattedDate() + "" + user.getName() + "上厕所");
17                Thread.sleep(2000);
18 
19 
20            }catch(InterrupteException ex){
21 
22                              
23 
24                             }Finally{
25                                semphore.release();
26                                   }
27 
28                         }
29 }
30 
31 public static void  main(String[] args){
32 
33 ExecutorService   executorService = Executors.newFixedThreadPool(10);
34 
35 Toilet toilet = new Toilet();
36 
37 for(int i = 0; i < 20; i++){
38 
39 executorService.submit(()->{
40        toilet.enter(new User(userName[random.nextInt(3)]));
41 });
42 }
43 
44 
45 
46  }

解释：

使用semphore定义，semphore就是一种锁机制，进了厕所，在门上加锁。

也就是每次只有三个人上厕所。

那么分布式环境怎么解决呢？

当然也是控制资源的访问频率，一般主流的设计思想有两种：

1.漏洞算法：把请求比作水，在请求入口和响应请求的服务之间加一个漏桶，桶中的水以恒定的速度流出，这样就保证了服务接收到的流量速度是稳定的。

如果桶里的水是满的状态的话，再进来的水也会直接溢出的（请求直接拒绝）。

2.令牌桶算法：控制发送到网络上的数据的数目，并允许突发数据的发送。（在处理请求的时候，先尝试在桶中获取令牌，如果没有拿到令牌，第一种就是直接返回拒绝请求，第二种就是等待一段时间，再次尝试获取令牌）。

google 的Guava包中的RateLimiter就是令牌桶算法。

其实这两种算法差别不大，一个是在接口处控制恒定的速率，另一种就是以恒定的速率放令牌。但是令牌桶的算法更灵活一些。

为什么这么说呢？

令牌桶相比漏桶来说有一个优势，能够满足突发流量的请求。

比如说：如果线上的环境资源很空闲，因为漏洞水流出的速度恒定，请求因为速度受限不会及时得到相应。在者说，现在漏洞的水速度是3个每秒，现在线上来了5个请求，全部进漏桶，漏桶里面现在也只有5个请求，但是也只能一秒处理3个请求。但是如果是；令牌桶算法的话，放入令牌的速度是3个每秒，假设令牌桶中已经有两个令牌了，这个时候来了5个请求，都能拿到令牌完成请求，因此令牌桶算法是面向需求的。

讲讲 Google Guava怎么实现令牌桶算法的？

API 很简单，只需要指定限流的速度，例如第一个，速度是每秒钟2个，如果是分钟级限流，你也可以设置为 0.2，代表1秒钟生成0.2 个令牌，1分钟限流为 12个。第二个例子是每秒钟5000，这个例子演示了如何通过限流器限制网络处理流量为每秒钟 5kb。5000个byte。

Guava 还有很多方法，如下：

返回值和方法修饰符方法和描述
double acquire()
从RateLimiter获取一个许可，方法会被阻塞直到获取到请求
double acquire(int permits)
从RateLimiter获取指定许可数，方法会被阻塞直到获取到请求
static RateLimiter create(double permitsPerSecond)
根据每秒放到令牌桶数量创建RateLimiter，这里的令牌桶数量是指每秒生成令牌数（通常是指QPS，每秒多少查询）
static RateLimiter create(double permitsPerSecond, long warmupPeriod, TimeUnit unit)
根据每秒放到令牌桶数量和预热期来创建RateLimiter，意思是不会一下生成全部的令牌，把令牌桶塞满，而是会渐进式的增加令牌，这里的每秒放到令牌桶数量是指每秒生成令牌数（通常是指QPS，每秒多少个请求量），在这段预热时间内，RateLimiter每秒分配的许可数会平稳地增长直到预热期结束时达到最大。
double getRate()
返回RateLimiter 配置中的稳定速率，该速率单位是每秒生成多少令牌数
void setRate(double permitsPerSecond)
更新RateLimite的稳定速率，参数permitsPerSecond 由构造RateLimiter的工厂方法提供。
boolean tryAcquire()
从RateLimiter 获取许可，如果该许可可以在无延迟下的情况下立即获取得到的话
boolean tryAcquire(int permits)
从RateLimiter 获取许可数，如果该许可数可以在无延迟下的情况下立即获取得到的话
boolean tryAcquire(int permits, long timeout, TimeUnit unit)
从RateLimiter 获取指定许可数如果该许可数可以在不超过timeout的时间内获取得到的话，或者如果无法在timeout 过期之前获取得到许可数的话，那么立即返回false （无需等待）