高并发场景下的限流策略

Posted 2020-12-20

高并发场景下的限流策略

在高并发的场景下，我们的优化和保护系统的方式通常有：多级缓存、资源隔离、熔断降级、限流等等。
今天我们来聊聊限流。

为什么需要限流

---

举个比较简单的例子，正常来说，一个员工A他每天能够处理的工作是10个，突然某一天来了100个工作量，这时候，如果员工A还处理100个，只有一种可能，这个员工被压垮。
如果我们能预先知道会有100个任务会来，我们通过增加员工数或定义消息队列等等来临时解决。

但是我们很多时候无法预料这些意外的。根据墨菲定律，坏事往往会接踵而来，有可能某个点挂了会引起全局的挂掉（雪崩）。因此我们不得不对我们的系统做一些保护措施。限流是其中之一。

针对秒杀这类场景，我们也可以做一些限流措施，而不影响到系统全局。

限流方式之计数器(滑动窗口协议)

---

思路：限速，我们可能第一个想到的应该是，我通过一个计数器，进行技术，如果超过了计数器阀值，表示速度太快了。一秒一个计数器。

计数器.png
为了便于阅读，我只截图了主要的代码片段。

代码片段
这样有个问题就是：粒度太大了，不均匀，针对1秒以下的，没法辨析。

我们能不能把粒度拆细了，1秒拆成10个100毫秒。每一个100毫秒有一个计数器。了解TCP/IP的应该知道，TCP/IP为了增加传输速度和控制传输速度，有个叫“滑动窗口协议”。

就算拆得再细，也无法解决匀速限制速度的问题。

而且还有个临界点问题，假如，一秒限制10个请求，在第1秒和第2秒之间，第1秒后半段时间10个请求，第2秒前半段10个请求，那第1秒后半段+第2秒前半段时间组成的一秒钟里就有20个请求，没有起到限速的作用。

有没有更好的办法呢？

限速方式之漏桶算法

---

在生活中，如果一桶有一个细眼，我们往里面装水，可以看到水是一滴一滴匀速的下落的，哪我们能不能通过程序来实现这种方式呢。
思路：桶为容器，一滴水为一请求。如果桶满了就拒绝请求，没满处理请求。

漏桶算法.png
代码片段

漏桶算法

在段代码中

• 首先计算这次请求与上次请求来的时候，总共漏了多少水。
• 看一下桶里面还剩多少水，有没有溢出。
• 如果溢出了拒绝请求，如果没有添加当前一滴水。处理请求。

对于很多应用场景来说，除了要求能够限制数据的平均传输速率外，还要求允许某种程度的突发传输。这时候漏桶算法可能就不合适了，令牌桶算法更为适合。

什么意思呢？就是说我服务前面闲了很久，突然来了很多请求（在桶的容量内），我得快速的把这些处理了。

限速方式之令牌桶算法

---

思路：匀速的产生令牌，往桶里面丢，每次请求来，看是否有多余的令牌。如果有获取令牌执行正常业务，偌没有限速。
令牌桶.png
代码片段

令牌桶代码

通过这种方式可以允许瞬时的大量处理，然后做限速处理。

• 请求来的时候先计算目前放入桶中的令牌数，这里计算，就可以不用启动一个线程匀速放置令牌了，这个叫惰性计算。
• 然后计算桶拥有的令牌数。然后获取令牌。做拒绝还是处理动作。
  以上代码，可在Github查看。
  https://github.com/hirudy/java_lib/tree/master/src/main/java/com/hirudy/limiter

单机限速器RateLimiter

---

安利大家一个高效的限速器。
google的基础库guava中包含了一个基于令牌桶的限速器RateLimiter。使用也很简单。

测试样例
本文来自作者投稿，原作者『林湾村龙猫』，可以搜索林湾村龙猫关注他的公众号。

直面Java第150期：什么是动态代理？
成神之路第014期：Java8中Stream的用法。

• MORE | 更多精彩文章 -
• 寻找锦鲤程序员
• 官宣！准备了两万块钱的福利，见者有份~
• 过来人的经验：培训到底有没有用
• 漫话解释数据库的脏读、不可重复读和幻读

如果你看到了这里，说明你喜欢本文。
那么请长按二维码，关注Hollis

转发朋友圈，是对我最大的支持。