限流算法与简单实现

一、限流的场景

在解释「服务限流」之前，我们来看一下前些时间网上很火的一个段子，说的是新浪微博的一名工程师正在家里办婚礼，突然接到公司的电话要紧急处理线上流量激增的问题，那天应该是某当红明星突然在微博上公布恋情，微博流量突增好几倍，导致系统功能出现不稳定，用户访问不畅。然后这名工程师就只好晾开新娘，在婚礼现场穿着西装打开笔记本调试代码了。

通常来说，我们的应用服务器的资源是有限的，可以同时处理的请求数量有限。那一旦有超过系统处理能力的请求过来，就有可能把服务器打挂，导致无法正常提供服务。那这个时候一般该进行如何处理呢？

其实这时也应该分情况处理，如果是618、双十一这种时候，可能是由于用户太多，那这种情况一般只能做服务降级，可以暂时不提供一些不重要的服务（如评论等），或者返回默认数据，从而保证核心功能（下单）不受影响；但是如果是突然的爬虫请求，就应该进行限流。

二、常见的限流算法

1.计数器

（1）基本思想

比如我们限制一秒钟能处理的请求为100个，那么记录秒处理的请求，一旦个数达到100之后，就拒绝这一秒内到达的其他请求。

（2）优点

• 简单容易实现。
• 可以利用redis记录，从而实现分布式集群限流。
• 可以针对不同的请求，分别计数，从而实现不同的流量限制。也可以针对用户、IP等进行限流，因此比较灵活

（3）缺点

• 有“突刺现象”，如果在单位时间1s内的前10ms，已经通过了100个请求，那后面的990ms，只能眼巴巴的把请求拒绝，我们把这种现象称为“突刺现象”。

2. 漏桶算法

（1）基本思想

想象有一个木桶，以恒定的速度漏水（处理请求），有新的请求来，可以放进桶里，如果桶满了，则直接拒绝请求。

（2）优点

可以平滑收到的请求，以恒定的速度处理。

（3）缺点

请求的处理有一定的延时性，要注意不能使延时超过调用者的忍受范围。

3. 令牌桶算法

（1）基本思想

想象有一个木桶，以恒定的速度往里面放入令牌。有新的请求来，如果桶里面还有令牌，则取出一个令牌，并处理该请求；如果桶里已经没有令牌了，则直接拒绝请求。

（2）优点

允许一定程度的突发，比如可能瞬时有挺多请求，只要桶里面有令牌，就可以马上处理。