SmoothBursty

主要思想

记录 1秒内的微秒数/permitsPerSencond = 时间间隔interval,每一个interval可获得一个令牌

根据允许使用多少秒内的令牌参数,计算出maxPermits

setRate时初始化下次interval时间,及storedPermits

acquire时,计算当前nowMicros,如果大于下次interval时间时间,则更新storedPermits和下次interval时间,计算storedPermits能否满足此次acquire,如果能,则需要等待的时间为0,如果不能,则计算还需要多少微秒等待,并在非同步块外执行sleep操作

如果其他线程已经刷新了nextFreeTicketMicros,会如下情况acquire是无timeout的

Thread 1: acquire 11 -> storedPermits不能满足要求 -> waitTime = (acquire - stored) * stableIntervalMicros -> nextFreeTicketMicros += waitMicros ----->  out lock sleep
Thread 2: acquire 2 -> nowMicros < nextFreeTicketMicros , stored = 0,被线程1消耗完了 -> freshPermits = requiredPermits - storedPermitsToSpend 即 = requiredPermits -> waitTime = freshPermits * stableIntervalMicros
-> nextFreeTicketMicros += waitTime,此时的nextFreeTicketMicros包含了Thread1需要等待的时间 -------> out lock sleep a longer time

tryAquire(num,timeout)逻辑

timeoutMicros = timeout.toMicros
lock()
nowMicros = ...
canAcquire = nextFreeTicketMicros <= nowMicros + timeoutMicros
if(!canAcquire){
return false;
}
else{
microsToWait = ...
}
unlock()
sleep(microsToWait)
return true;

SmoothWarmingUp

主要思想和SmoothBursty相似,由于带预热过程,刚开始由于availablePermitsAboveThreshold>0.0,速率会较慢,如果持续获取令牌,则会使availablePermitsAboveThreshold=0,速率变快

  • 从0->thresholdPermits,生成一个令牌的时间:stableIntervalMicros

  • 从thresholdPermits-> maxPermits ,生成一个令牌的时间:stableIntervalMicros + permits * slope;

    @Override

    final long reserveEarliestAvailable(int requiredPermits, long nowMicros) {

    resync(nowMicros);

    long returnValue = nextFreeTicketMicros;

    //当前需要且尽最大可能消费的

    double storedPermitsToSpend = min(requiredPermits, this.storedPermits);

    //新鲜permits个数,这些个数是一定会产生等待的,除了0

    double freshPermits = requiredPermits - storedPermitsToSpend;

    //计算需要wait的总时间

    long waitMicros =

    //非busty类型的storedPermitsToWaitTime直接返回0

    storedPermitsToWaitTime(this.storedPermits, storedPermitsToSpend)

    + (long) (freshPermits * stableIntervalMicros);

    //下次有票时间

    this.nextFreeTicketMicros = LongMath.saturatedAdd(nextFreeTicketMicros, waitMicros);

    this.storedPermits -= storedPermitsToSpend;

    return returnValue;

    }

     //已知permitsToTake <= storedPermits
    @Override
    long storedPermitsToWaitTime(double storedPermits, double permitsToTake) {
    //减去预热需要保留的permits,剩下的可消耗的数量
    double availablePermitsAboveThreshold = storedPermits - thresholdPermits;
    long micros = 0;
    // measuring the integral on the right part of the function (the climbing line)
    //如果有剩余可用的令牌
    if (availablePermitsAboveThreshold > 0.0) {
    //剩余可用的和需要获取的个数取小值
    double permitsAboveThresholdToTake = min(availablePermitsAboveThreshold, permitsToTake);
    // TODO(cpovirk): Figure out a good name for this variable.
    //用可消耗的数量 + (可消耗的数量 - 实际消耗的数量)permitsToTime
    //在预热阶段从thresholdPermits到maxPermits的耗时并非是stableIntervalMicros * n
    //会耗费更多的时间,其计算规则不同,所以才需要把permitsAboveThresholdToTake从permitsToTake减去
    //length 可能作为一个经验值,相当于补充permitsAboveThresholdToTake个令牌需要的平均时间值*2
    //剩余可用的-实际需要且最大能消耗的令牌,得到最终剩余的令牌个数,可能是0
    double length = permitsToTime(availablePermitsAboveThreshold)
    + permitsToTime(availablePermitsAboveThreshold - permitsAboveThresholdToTake);
    //这里确实不好理解,从语义环境来说,它是从 thresholdPermits 到 maxPertmis 过程中
    //生成 permitsAboveThresholdToTake 个令牌需要耗费的时间
    //并且带coldFactor的构造函数不是public,SmoothWarmingUp也是private-package的
    micros = (long) (permitsAboveThresholdToTake * length / 2.0);
    //从permitsToTake中减去保留预热需留下个数后最终消耗的个数,这部分个数由于是提前存在的、富余的
    //因此不需要计算到wait时间
    permitsToTake -= permitsAboveThresholdToTake;
    }
    // measuring the integral on the left part of the function (the horizontal line)
    //如果没有剩余可用令牌,走的是stableIntervalMicros * n
    micros += (stableIntervalMicros * permitsToTake);
    return micros;
    }

length/2可以理解为下图

	//permits值越小,需要的时间就越少,值越大,需要的时间就越大
private double permitsToTime(double permits) {
//double coldIntervalMicros = stableIntervalMicros * coldFactor;
// thresholdPermits = 0.5 * warmupPeriodMicros / stableIntervalMicros;
//maxPermits =
thresholdPermits + 2.0 * warmupPeriodMicros / (stableIntervalMicros + coldIntervalMicros);
//slope带比率的时间,可以理解为增长因子
//slope = (coldIntervalMicros - stableIntervalMicros) / (maxPermits - thresholdPermits)
//return表示成这样更易于理解 stableIntervalMicros + (coldIntervalMicros - stableIntervalMicros) * (permits/(maxPermits - thresholdPermits))
return stableIntervalMicros + permits * slope;
}

RateLimiter的 SmoothBursty(非warmup预热)及SmoothWarmingUp(预热,冷启动)的更多相关文章

  1. 超详细的Guava RateLimiter限流原理解析

    超详细的Guava RateLimiter限流原理解析  mp.weixin.qq.com 点击上方“方志朋”,选择“置顶或者星标” 你的关注意义重大! 限流是保护高并发系统的三把利器之一,另外两个是 ...

  2. RateLimiter 源码分析(Guava 和 Sentinel 实现)

    作者javadoop,资深Java工程师.本文已获作者授权发布. 原文链接https://www.javadoop.com/post/rate-limiter 本文主要介绍关于流控的两部分内容. 第一 ...

  3. 高并发之限流RateLimiter(二)

    Guava RateLimiter提供了令牌桶算法实现:平滑突发限流(SmoothBursty)和平滑预热限流(SmoothWarmingUp)实现. SmoothBursty:令牌生成速度恒定 @T ...

  4. 面试官:来谈谈限流-RateLimiter源码分析

    RateLimiter有两个实现类:SmoothBursty和SmoothWarmingUp,其都是令牌桶算法的变种实现,区别在于SmoothBursty加令牌的速度是恒定的,而SmoothWarmi ...

  5. 使用Guava RateLimiter限流入门到深入

    前言 在开发高并发系统时有三把利器用来保护系统:缓存.降级和限流 缓存: 缓存的目的是提升系统访问速度和增大系统处理容量 降级: 降级是当服务出现问题或者影响到核心流程时,需要暂时屏蔽掉,待高峰或者问 ...

  6. RateLimiter源码解析

    RateLimiter是Guava包提供的限流器,采用了令牌桶算法,特定是均匀地向桶中添加令牌,每次消费时也必须持有令牌,否则就需要等待.应用场景之一是限制消息消费的速度,避免消息消费过快而对下游的数 ...

  7. Java技术开发专题系列之【Guava RateLimiter】针对于限流器的入门到精通(针对于源码分析介绍)

    Guava包中限流实现分析 RateLimiter 之前的文章中已经介绍了常用的限流算法,而google在Java领域中使用Guava包中的限流工具进行服务限流. 回顾使用案例 Google开源工具包 ...

  8. 常用限流算法与Guava RateLimiter源码解析

    在分布式系统中,应对高并发访问时,缓存.限流.降级是保护系统正常运行的常用方法.当请求量突发暴涨时,如果不加以限制访问,则可能导致整个系统崩溃,服务不可用.同时有一些业务场景,比如短信验证码,或者其它 ...

  9. RateLimiter令牌桶算法

    限流,是服务或者应用对自身保护的一种手段,通过限制或者拒绝调用方的流量,来保证自身的负载. 常用的限流算法有两种:漏桶算法和令牌桶算法 漏桶算法 思路很简单,水(请求)先进入到漏桶里,漏桶以一定的速度 ...

随机推荐

  1. python库之argparse

    先运行一个干净的argparse 由于没有添加任何参数,所以只能用自带的 -h(--help)参数 现在来加一个参数 所以echo为必填项 描述在-h时会出现 type=int指定参数只能是数字,否则 ...

  2. springboot+websocket实现简单的在线聊天功能

    效果如下: java实现逻辑: 1.引入maven依赖 <dependency> <groupId>org.springframework.boot</groupId&g ...

  3. 《穷查理年鉴》习惯 & 工作 & 自省 & 自律 (关于自己)

    习惯 001.在那充满古老年鉴的年代里,扔掉你的恶行,不管它们曾经给你带来多大的好处. 002.许多关于预言的争论都可以简化为:当你说是时,就有人说浊;当你认为不是时,一定有人说是. 003.坏习惯和 ...

  4. Talk is cheap. Show me the code的由来

    Date: Fri, 25 Aug 2000 11:09:12 -0700 (PDT) From:Linus Torvalds Subject Re: SCO: "thread creati ...

  5. Java之ConcurrentHashMap源码解析

    ConcurrentHashMap源码解析 目录 ConcurrentHashMap源码解析 jdk8之前的实现原理 jdk8的实现原理 变量解释 初始化 初始化table put操作 hash算法 ...

  6. SpringBoot 完整学习笔记免费分享

    从0到进阶,完全系统性的学习笔记 每次我都会反复拿来观看,因为我们总会有遗漏忘记的地方,但是笔记不会. 希望大家能好好利用它,以下是笔记截图! 以上只是其中的一项部分,这份笔记可以说含金量超高,绝对会 ...

  7. JVM性能调优(4) —— 性能调优工具

    前序文章: JVM性能调优(1) -- JVM内存模型和类加载运行机制 JVM性能调优(2) -- 垃圾回收器和回收策略 JVM性能调优(3) -- 内存分配和垃圾回收调优 一.JDK工具 先来看看有 ...

  8. ztree通过ajax加载json数据中文乱码的解决方法:springmvc配置

    一.问题描述 使用zTree的异步刷新父级菜单时,服务器返回中文乱码,但项目中使用了SpringMvc,已经对中文乱码处理,为什么还会出现呢? 此处为的异步请求的配置: async: { enable ...

  9. 实验三 HTML表格和表单的制作

    实验三 HTML表格和表单的制作 [实验目的] 1.掌握表格的创建.结构调整与美化方法: 2.熟悉表格与单元格的主要属性及其设置方法: 3.掌握通过表格来进行网页页面的布局方法. [实验环境] 连接互 ...

  10. 还不会ida*算法?看完这篇或许能理解点。

    IDA* 算法分析 IDA* 本质上就是带有估价函数和迭代加深优化的dfs与,A * 相似A *的本质便是带 有估价函数的bfs,估价函数是什么呢?估价函数顾名思义,就是估计由目前状态达 到目标状态的 ...