聊一聊限流

说起限流，技术人员应该都有所了解，也就是限制流量，先讲几个例子：

1）旅游景点；很多人去过故宫，每逢节假日都会迎来人流高峰，为了维护秩序和安全，每天限定售票数量

2）银行柜台；银行一般会设置几个服务窗口，柜台满了其他人要排队

3）超市领免费赠品；每天早上大爷大妈排队去超市领免费柴米油盐

这些都是日常生活中我们遇到的典型的限流的场景，那么为什么要限流？对于1）如果不限流那么可能出现踩踏、文物损坏等严重的问题，对于2）如果不设置银行柜台会出现秩序混乱，工作人员服务不过来，对于3）如果不限制可

能你超市就空了。

从以上几点可以简单总结出限流的目的是：

1）主体处理能力有限，自我保护

2）流量过大导致主体响应能力变弱，避免客户长时间无效等待

那么反映到系统或者网站应用中，应用是由程序组成，程序又搭建在服务器或者虚拟主机上，程序的响应能力和服务器的处理能力直接决定了应用的并发处理能力。按照限流的粒度一般有两种类型的限流方式：

I）应用级限流；将在应用入口处限制流量，对系统保护效果更好

II）接口级限流；一般核心业务的qps要远远比非核心业务的大，对核心业务的接口做有效的限流，也能很好的保护应用

III）数据库限流；如果数据库实例对应单应用，可以不用限制，在上层就可以拦掉，但是如果一个数据库实例被多个应用共用就要考虑数据库限流，否则可能一个应用把数据库拖挂导致其他应用也崩溃了

所谓的限流，其实有两个关键的点需要区分，并发性和频率。并发性是指同一时刻允许的请求数量，而频率是指某个时间段里限制访问多少次，其实就是点和线的关系，具体实际应用中怎么使用，还是要以具体的业务场景来裁定。实际的应用场景中在限流时，常见的两种算法是漏桶和令牌桶算法算法，接下来注意描述其原理以及二者的区别。

一、漏桶算法

漏桶算法思路很简单，水（数据或者请求）先进入到漏桶里，漏桶以一定的速度出水，当水流入速度过大会直接溢出，可以看出漏桶算法能强行限制数据的传输速率。漏桶可以看作是一个带有常量服务时间的单服务器队列，如果漏桶（包缓存）溢出，那么数据包会被丢弃，漏桶算法可以很好的控制流量的访问速度，一旦超过该速度就拒绝服务。

二、令牌桶算法（Token Bucket）

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

两者主要区别在于“漏桶算法”能够强行限制数据的传输速率，而“令牌桶算法”在能够限制数据的平均传输速率外，还允许某种程度的突发传输。在“令牌桶算法”中，只要令牌桶中存在令牌，那么就允许突发地传输数据直到达到用户配置的上限，所以它适合于具有突发特性的流量。

至于限流的具体实现方式，Guava提供了RateLimiter基于令牌桶的实现(单机版)，基于Semaphore也可以实现限流，也可以结合redis或者zookeeper实现分布式限流，具体使用和实现方式后续篇章中会讲述。