高并发场景下的限流和降级
什么是限流和降级
在开发高并发系统时,有很多手段来保护系统:缓存、降级、限流。
当访问量快速增长、服务可能会出现少量问题(响应超时),或者者会存在非核心服 务影响到核心流程的性能时, 依然需要保证服务的可用性,即使是有损服务。 所以意味着我们在设计服务的时候,需要少量手段或者者关键数据进行自动降级,或者者配置人工降级的开关。
缓存的目的是提升系统访问速度和增大系统解决的容量,可以说是抗高并发流量的银弹;
降级是当服务出问题或者者影响到核心流程的性能则需要暂时屏蔽掉某些功能,等高 峰或者者问题处理后再打开;而有些场景并不能用缓存和降级来处理,比方秒杀、抢 购;写服务(评论、下单)、频繁的复杂查询,因而需要一种手段来限制这些场景 的并发/请求量
降级
对于高可用服务的设计,有一个很重要的设计,那就是降级。降级一般有几种实现 手段,自动降级和人工降级
通过配置降级开关,实现对流程的控制
前置化降级开关, 基于 OpenResty+配置中心实现降级
业务降级,在大促的时候,我们会有限保证核心业务的流程可用,也就是下单 支付。同时,我们也会对核心的支付流程采取少量异步化的方式来提升吞吐量
限流
限流的目的是防止恶意请求流量、恶意攻击、或者者防止流量超过系统峰值 限流是对资源访问做控制的一个组件或者者功能,那么控制这块主要有两个功能:限流策略和熔断策略,对于熔断策略,不同的系统有不同的熔断策略诉求,有得系统希望直接拒绝服务、有的系统希望排队等待、有的系统希望服务降级。限流服务 这块有两个核心概念:资源和策略资源:被流量控制的对象,比方接口策略:限流策略由限流算法和可调节的参数两部份组成
限流的目的是通过对并发访问/请求进行限速或者者一个时间窗口内的请求进行限速 来保护系统,一旦达到限制速率则可以拒绝服务(定向到错误页或者者告知资源没有 了)、排队或者等待(秒杀、下单)、降级(返回兜底数据或者默认数据或者默认数据,如商品介绍页库存默认有货)
限流和降级
滑动窗口协议是传输层进行流控的一种措施,接收方通过通告发送方自己的窗口大小,从而控制发送方的发送速度,从而达到防止发送方发送速渡过快而导致自己被淹没的目的。
简单解释下,发送和接受方都会维护一个数据帧的序列,这个序列被称作窗口。发 送方的窗口大小由接受方确定,目的在于控制发送速度,以免接受方的缓存不够大, 而导致溢出,同时控制流量也可以避免网络拥塞。下面图中的 4,5,6 号数据帧已经 被发送出去,但是未收到关联的 ACK,7,8,9 帧则是等待发送。可以看出发送端的 窗口大小为 6,这是由接受端告知的。此时假如发送端收到 4 号 ACK,则窗口的左 边缘向右收缩,窗口的右边缘则向右扩展,此时窗口就向前“滑动了”,即数据帧 10 也可以被发送
动态效果演示
什么是限流和降级
在开发高并发系统时,有很多手段来保护系统:缓存、降级、限流。
当访问量快速增长、服务可能会出现少量问题(响应超时),或者者会存在非核心服 务影响到核心流程的性能时, 依然需要保证服务的可用性,即使是有损服务。 所以意味着我们在设计服务的时候,需要少量手段或者者关键数据进行自动降级,或者者配置人工降级的开关。
缓存的目的是提升系统访问速度和增大系统解决的容量,可以说是抗高并发流量的银弹;
降级是当服务出问题或者者影响到核心流程的性能则需要暂时屏蔽掉某些功能,等高 峰或者者问题处理后再打开;而有些场景并不能用缓存和降级来处理,比方秒杀、抢 购;写服务(评论、下单)、频繁的复杂查询,因而需要一种手段来限制这些场景 的并发/请求量
降级
对于高可用服务的设计,有一个很重要的设计,那就是降级。降级一般有几种实现 手段,自动降级和人工降级
通过配置降级开关,实现对流程的控制
前置化降级开关, 基于 OpenResty+配置中心实现降级
业务降级,在大促的时候,我们会有限保证核心业务的流程可用,也就是下单 支付。同时,我们也会对核心的支付流程采取少量异步化的方式来提升吞吐量
限流
限流的目的是防止恶意请求流量、恶意攻击、或者者防止流量超过系统峰值 限流是对资源访问做控制的一个组件或者者功能,那么控制这块主要有两个功能:限流策略和熔断策略,对于熔断策略,不同的系统有不同的熔断策略诉求,有得系统希望直接拒绝服务、有的系统希望排队等待、有的系统希望服务降级。限流服务 这块有两个核心概念:资源和策略资源:被流量控制的对象,比方接口策略:限流策略由限流算法和可调节的参数两部份组成
限流的目的是通过对并发访问/请求进行限速或者者一个时间窗口内的请求进行限速 来保护系统,一旦达到限制速率则可以拒绝服务(定向到错误页或者者告知资源没有 了)、排队或者等待(秒杀、下单)、降级(返回兜底数据或者默认数据或者默认数据,如商品介绍页库存默认有货)
限流和降级
滑动窗口协议是传输层进行流控的一种措施,接收方通过通告发送方自己的窗口大小,从而控制发送方的发送速度,从而达到防止发送方发送速渡过快而导致自己被淹没的目的。
简单解释下,发送和接受方都会维护一个数据帧的序列,这个序列被称作窗口。发 送方的窗口大小由接受方确定,目的在于控制发送速度,以免接受方的缓存不够大, 而导致溢出,同时控制流量也可以避免网络拥塞。下面图中的 4,5,6 号数据帧已经 被发送出去,但是未收到关联的 ACK,7,8,9 帧则是等待发送。可以看出发送端的 窗口大小为 6,这是由接受端告知的。此时假如发送端收到 4 号 ACK,则窗口的左 边缘向右收缩,窗口的右边缘则向右扩展,此时窗口就向前“滑动了”,即数据帧 10 也可以被发送
动态效果演示
漏桶
image-20181127153258192.png
桶本身具备一个恒定的速率往下漏水,而上方时快时慢的会有水进入桶内。当桶还 未满时,上方的水可以加入。一旦水满,上方的水就无法加入。桶满正是算法中的 一个关键的触发条件(即流量异常判断成立的条件)。而此条件下如何解决上方流 下来的水,有两种方式:
暂时阻拦住上方水的向下流动,等待桶中的一部分水漏走后,再放行上方水。
溢出的上方水直接抛弃 特点
漏水的速率是固定的
即便存在注水 burst(忽然注水量变大)的情况,漏水的速率也是固定的
令牌桶(能够处理突发流量)
令牌桶算法是网络流量整形(Traffic Shaping)和速率限制(Rate Limiting)中最常使用的一种算法。典型情况下,令牌桶算法用来控制发送到网络上的数据的数目,并允许突发数据的发送。
令牌桶是一个存放固定容量令牌(token)的桶,按照固定速率往桶里增加令牌; 令牌桶算法实际上由三部分组成:两个流和一个桶,分别是令牌流、数据流和令牌桶
image-20181127153946953.png
限流算法的实际应用
Guava 的 RateLimiter 实现
在 Guava 中 RateLimiter 的实现有两种: Bursty 和 WarmUp
bursty
bursty 是基于 token bucket 的算法实现,比方
RateLimiter rateLimiter=RateLimiter.create(permitPerSecond);
//创立一个 bursty 实例
rateLimiter.acquire();
//获取 1 个 permit,当令牌数量不够时会阻塞直到获取为止
WarmingUp
基于 Leaky bucket 算法实现
QPS 是固定的
使用于需要预热时间的使用场景
//创立一个 SmoothWarmingUp 实例;warmupPeriod 是指预热的时间 RateLimiter create(double permitsPerSecond, long warmupPeriod, TimeUnit unit) RateLimiter rateLimiter =RateLimiter.create(permitsPerSecond,warmupPeriod,timeUnit); rateLimiter.acquire();//获取 1 个 permit;可能会被阻塞止到获取到为止
<dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> <version>27.0-jre</version></dependency>
public class Token { //guava->令牌桶、漏桶 //bursty(令牌桶) RateLimiter rateLimiter=RateLimiter.create(10); //qps是1000 //漏桶 RateLimiter rateLimiter1=RateLimiter.create(1000,10, TimeUnit.MILLISECONDS); public void doPay(){ if(rateLimiter.tryAcquire()){ System.out.println(Thread.currentThread().getName()+"开始执行支付"); }else { System.out.println("系统繁忙"); } } public static void main(String[] args) throws IOException { Token token=new Token(); CountDownLatch countDownLatch=new CountDownLatch(1); Random random=new Random(10); for (int i = 0; i < 20; i++) { new Thread(()->{ try{ countDownLatch.await(); Thread.sleep(random.nextInt(1000)); token.doPay(); } catch (InterruptedException e) { e.printStackTrace(); } }).start(); } countDownLatch.countDown(); System.in.read(); }}
差异化演示
import com.google.common.util.concurrent.RateLimiter;import java.util.concurrent.TimeUnit;public class TokenDemo { private int qps; private int countOfReq; private RateLimiter rateLimiter; public TokenDemo(int qps, int countOfReq) { this.qps = qps; this.countOfReq = countOfReq; } public TokenDemo processWithTokenBucket() { rateLimiter = RateLimiter.create(qps); return this; } //warmupPeriod 是指预热的时间 public TokenDemo processWithLeakyBucket() { rateLimiter = RateLimiter.create(qps, 00, TimeUnit.MILLISECONDS); return this; } private void processRequest() { System.out.println("RateLimiter:" + rateLimiter.getClass()); long start = System.currentTimeMillis(); for (int i = 0; i < countOfReq; i++) { rateLimiter.acquire(); } long end = System.currentTimeMillis() - start; System.out.println("解决请求数量:" + countOfReq + "," + "耗时:" + end + "," + "qps:" + rateLimiter.getRate() + "," + "实际 qps:" + Math.ceil(countOfReq / (end / 1000.00))); } public void doProcess() throws InterruptedException { for (int i = 0; i < 20; i = i + 5) { TimeUnit.SECONDS.sleep(i); processRequest(); } } public static void main(String[] args) throws InterruptedException { new TokenDemo(50, 100).processWithTokenBucket().doProcess(); new TokenDemo(50, 100).processWithLeakyBucket().doProcess(); }}
分布式下的限流策略
技术选型
mysql:存储限流策略的参数等元数据 redis+lua:令牌桶算法实现
具体实现
参考 Redisson 中的令牌桶实现逻辑就可
1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长!
2. 分享目的仅供大家学习和交流,您必须在下载后24小时内删除!
3. 不得使用于非法商业用途,不得违反国家法律。否则后果自负!
4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解!
5. 如有链接无法下载、失效或广告,请联系管理员处理!
6. 本站资源售价只是摆设,本站源码仅提供给会员学习使用!
7. 如遇到加密压缩包,请使用360解压,如遇到无法解压的请联系管理员
开心源码网 » 高并发场景下的限流和降级