服务限流

Posted 2021-04-20 不周山笔记

什么是限流

其实就是限制流量，限流可以认为服务降级的一种，限流就是限制系统的输入和输出流量已达到保护系统的目的。一般来说系统的吞吐量是可以被测算的，为了保证系统的稳定运行，一旦达到的需要限制的阈值，就需要限制流量并采取一些措施以完成限制流量的目的。比如：延迟处理，拒绝处理，或者部分拒绝处理等等。

为何要服务限流

一般来说流量越多越好，为何要限制呢。因为大多都是资源有限的，比如某个景点，一到了放假期间通常会人满为患，如果不做限制，景点会有安全隐患，超密集的人群也会影响游客的体验。但由于景区名气大，来游玩的旅客络绎不绝，远超出了景区的承载能力，因此景区只好做出限制每日人员流量的举措。
同样的对于服务来说如果某个服务突然出现很多人访问超出的系统的负载的时候，也有这个问题，相对的就会对服务进行限流。

限流的处理策略

1. 熔断：
   保险丝大家都知道，不管是家里的电路还是汽车里面的电路，一般都会有保险丝。熔断就是当某个服务出现不可用或响应超时的情况下，为了防止整个系统出现雪崩而暂时停止对该服务的调用。

2. 服务降级：
   服务降级为了防止因第三方服务出现的不可用或超时情况下，而在内部暂时舍弃对一些非核心的接口和数据的请求，直接返回一个提前准备好的fallback（退路）错误处理信息。

3. 延迟处理：
   这个模式需要在系统的前端设置一个流量缓冲池，将所有的请求全部缓冲进这个池子，不立即处理。然后后端真正的业务处理程序从这个池子中取出请求依次处理，常见的可以用队列模式来实现。相当于用异步的方式去减少了后端的处理压力，但是当流量较大时，后端的处理能力有限，缓冲池里的请求可能处理不及时，会有一定程度延迟

限流算法

• 计数器
  计数器算法是限流算法里最简单也是最容易实现的一种算法，每当一个请求到来时，将计数器加一，当计数器数值超过阈值后，就拒绝余下请求。一秒钟后，将计数器清零，开始新一轮的计数。这个算法虽然简单，但是有一个十分明显的问题，那就是分配不均匀。比如我们限制一分钟内只能通过100次请求，那么前5秒内就已经请求100次了，那么后55秒内的请求只能拒绝，导致请求分配不均匀。简单实现：

  
  

• 漏斗
  漏桶算法由流量容器、流量入口和出口组成。其中流量出口流速即为我们期望的限速值，比如 100 QPS。漏桶算法除了具备限流能力，还具备流量整型功能。
  
  如上图，流入漏桶流量的流速是不恒定的，经过漏桶限速后，流出流量的速度是恒定的。需要说明的是，漏桶的容量是有限的，一旦流入流量超出漏桶容量，这部分流量只能被丢弃了。漏桶是一个比较好的限流整型工具，不过漏桶不能处理突发流量，如果要找一种能够支持突发流量的限流算法，那么令牌桶算法可以满足需求。该实现可以用一个阻塞队列进行实现。

• 令牌桶
  令牌桶和漏桶颇有几分相似，只不过令牌通里存放的是令牌。令牌桶示意图：
  
  对于令牌桶来说，你可以采用定时任务去做投递令牌的动作，也可以采用算法的方式去进行简单的计算。当令牌桶满了后，多出的令牌会被丢弃掉。每当一个请求到来时，该请求对应的线程会从令牌桶中取令牌。初期由于令牌桶中存放了很多个令牌，因此允许多个请求同时取令牌。当桶中没有令牌后，无法获取到令牌的请求可以丢弃，或者重试。该实现典型有google的Guava类Ratelimter。

分布式限流

以上的几个算法都是基于单机运行的，对于分布式的限流目前也有很多种方案。

• 基于Redis
  由于要做限流，那么肯定有key来记录限流的累加数，此key可以随着时间进行任意变动。而且key需要设置过期参数，防止无效数据过多而导致redis性能问题。

• nginx
  nginx作为广泛使用的负载均衡器，功能也是十分齐全
  limit_req_zone：用来限制单位时间内的请求数，即速率限制,采用的漏桶算法 “leaky bucket”。
  limit_req_conn：用来限制同一时间连接数，即并发限制,具体的如何配置可以查看官方文档。

总结

限流是高可用治理中核心的一环，实现方式也五花八门，每种方式也都有各自的问题。希望随着 ServiceMesh、AIOps 等理论的兴起，对于限流是什么，能做什么，怎么实现，能够释放出更大的空间去想象。以上限流方式，主要是起抛砖引玉的作用，期待大家更好更优的解决方法。