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. JavaFX桌面应用-构建程序框架

    看到JavaFX应用很多人都会说JavaFX应用太丑了,确实JavaFX比起Qt.MFC.Delphi这些界面确实丑了一点,但也不是没有可以美化的空间. 跟网页一样,单纯HTML不加任何CSS的时候也 ...

  2. SpringBoot-03-配置之yaml语法学习

    3. SpringBoot配置 3.1 yaml语法学习 配置文件 Springboot使用一个全局的配置文件,配置文件名称固定 spplication.properties 语法结构:key=val ...

  3. JVM学习(八)指令重排序

    一.数据依赖性 在学习JVM的指令重排序之前,我们先了解一下什么是数据依赖性: 编译器和处理器在处理具体的指令时,可能会对操作进行重排序来提高执行性能[多条指令并行执行,所以提升性能的同时也可能会导致 ...

  4. Java源码赏析(一)Object 类

    写这个系列的原因,其实网上已经有无数源码分析的文章了,多一篇不多,少一篇不少,但为什么还要写这部分文章呢?于私,其一,上班族已经很久没有打过完整的一整段有意义的话,算是锻炼个人的书写.总结能力,其二, ...

  5. 吴恩达-机器学习+正则化regularization

  6. (转载)Altium Designer 17 (AD17)

    转载自:http://blog.csdn.net/qq_29350001/article/details/52199356 以前是使用DXP2004来画图的,后来转行.想来已经有一年半的时间没有画过了 ...

  7. 开源 C#工作流管理平台

    { font-family: 宋体; panose-1: 2 1 6 0 3 1 1 1 1 1 } @font-face { font-family: "Cambria Math" ...

  8. Arduino - 串口操作函数与示例代码大全

    来源:https://blog.csdn.net/iracer/article/details/50334041 Arduino - 串口操作函数与示例代码大全 本文总结了Arduino常用串口操作函 ...

  9. HTML & CSS & JavaScript 从一个表格到一个灰阶颜色表 02

    工具1:HBuilder X 1.9.9.20190522 工具2:火狐浏览器 67.0.4 (64 位) 其实,我想使用表格,做一个这样的颜色表,如下图所示: 例 3:我们参照上图,基于上一个例子, ...

  10. LiteOS-任务篇-源码分析-删除任务函数

    目录 前言 笔录草稿 源码分析 LOS_TaskDelete函数源码分析 完整源码 参考 链接 前言 20201009 LiteOS 2018 需要会通用链表 笔录草稿 源码分析 LOS_TaskDe ...