网站建设需求材料,wordpress+扫码付款,平台电商有哪些,做网站常熟转载自 高并发场景下的限流策略
在高并发的场景下#xff0c;我们的优化和保护系统的方式通常有#xff1a;多级缓存、资源隔离、熔断降级、限流等等。
今天我们来聊聊限流。 为什么需要限流
举个比较简单的例子#xff0c;正常来说#xff0c;一个员工A他每天能够处理…转载自 高并发场景下的限流策略
在高并发的场景下我们的优化和保护系统的方式通常有多级缓存、资源隔离、熔断降级、限流等等。
今天我们来聊聊限流。 为什么需要限流
举个比较简单的例子正常来说一个员工A他每天能够处理的工作是10个突然某一天来了100个工作量这时候如果员工A还处理100个只有一种可能这个员工被压垮。
如果我们能预先知道会有100个任务会来我们通过增加员工数或定义消息队列等等来临时解决。
但是我们很多时候无法预料这些意外的。根据墨菲定律坏事往往会接踵而来有可能某个点挂了会引起全局的挂掉雪崩。因此我们不得不对我们的系统做一些保护措施。限流是其中之一。
针对秒杀这类场景我们也可以做一些限流措施而不影响到系统全局。 限流方式之计数器(滑动窗口协议)
思路限速我们可能第一个想到的应该是我通过一个计数器进行技术如果超过了计数器阀值表示速度太快了。一秒一个计数器。 为了便于阅读我只截图了主要的代码片段。 这样有个问题就是粒度太大了不均匀针对1秒以下的没法辨析。
我们能不能把粒度拆细了1秒拆成10个100毫秒。每一个100毫秒有一个计数器。了解TCP/IP的应该知道TCP/IP为了增加传输速度和控制传输速度有个叫“滑动窗口协议”。
就算拆得再细也无法解决匀速限制速度的问题。
而且还有个临界点问题假如一秒限制10个请求在第1秒和第2秒之间第1秒后半段时间10个请求第2秒前半段10个请求那第1秒后半段第2秒前半段时间组成的一秒钟里就有20个请求没有起到限速的作用。
有没有更好的办法呢 限速方式之漏桶算法
在生活中如果一桶有一个细眼我们往里面装水可以看到水是一滴一滴匀速的下落的哪我们能不能通过程序来实现这种方式呢。
思路桶为容器一滴水为一请求。如果桶满了就拒绝请求没满处理请求。 代码片段 在段代码中 首先计算这次请求与上次请求来的时候总共漏了多少水。 看一下桶里面还剩多少水有没有溢出。 如果溢出了拒绝请求如果没有添加当前一滴水。处理请求。 对于很多应用场景来说除了要求能够限制数据的平均传输速率外还要求允许某种程度的突发传输。这时候漏桶算法可能就不合适了令牌桶算法更为适合。 什么意思呢就是说我服务前面闲了很久突然来了很多请求在桶的容量内我得快速的把这些处理了。 限速方式之令牌桶算法
思路匀速的产生令牌往桶里面丢每次请求来看是否有多余的令牌。如果有获取令牌执行正常业务偌没有限速。 代码片段 通过这种方式可以允许瞬时的大量处理然后做限速处理。 请求来的时候先计算目前放入桶中的令牌数这里计算就可以不用启动一个线程匀速放置令牌了这个叫惰性计算。 然后计算桶拥有的令牌数。然后获取令牌。做拒绝还是处理动作。
以上代码可在Github查看。 https://github.com/hirudy/java_lib/tree/master/src/main/java/com/hirudy/limiter 单机限速器RateLimiter
安利大家一个高效的限速器。
google的基础库guava中包含了一个基于令牌桶的限速器RateLimiter。使用也很简单。
